Sobre Historias Clinicas

UNIVERSIDAD SIMN BOLVAR
Decanato de Estudios Profesionales

Coordinacin de Electrnica
Diseo de un equipo para el manejo de Historias Clnicas Electrnicas en el

Sistema Hospitalario Venezolano
Por:
Hildemar Celeste Amaro Arreaza
Sartenejas, enero de 2008

Diseo de un equipo para el manejo de Historias Clnicas Electrnicas en el

Sistema Hospitalario Venezolano
Por
Realizado con la Asesora de
Prof. Ricardo Silva (Tutor Acadmico)
INFORME FINAL DE CURSOS EN COOPERACIN TCNICA Y DESARROLLO

SOCIAL
Presentado ante la Ilustre Universidad Simn Bolvar
como requisito parcial para optar al ttulo de Ingeniero Electrnico

Diseo de un equipo para el manejo de Historias Clnicas Electrnicas en el Sistema
Hospitalario Venezolano
Informe final de Cursos en Cooperacin Tcnica y Desarrollo Social Presentado por Hildemar
Celeste Amaro Arreaza
REALIZADO CON LA ASESORA DE: Profesor Ricardo Silva (Tutor Acadmico)
RESUMEN
Se realiz el diseo de un equipo para el manejo de historias clnicas, Medicarro, adaptado
al Sistema Hospitalario de Venezuela. El proyecto se desarroll a travs de cinco fases. La
primera consisti en el estudio de la estructura y funcionamiento del sistema hospitalario, los
procedimientos de bsqueda y consulta de historias clnicas, estableciendo la necesidad de
implementar un equipo para el manejo de registros mdicos electrnicos. En la segunda fase
se analizaron las diversas herramientas, procedimientos, y soluciones comerciales empleadas
en la actualidad, adaptables a Venezuela. Los requerimientos de Hardware, Software y
Operatividad constituyeron el punto de partida para el planteamiento de la propuesta. En la
tercera fase se procedi a la integracin de requerimientos, conocimientos y soluciones, que
concluy en el diseo del Medicarro; se propuso un procedimiento para su funcionamiento,
transmisin y acceso de datos de pacientes. En la cuarta etapa, se elabor un plan de asistencia
tcnica del equipo diseado, para el diagnstico y procedimientos a seguir en caso de fallas.
Por ltimo, se estudi su factibilidad econmica y se plantearon posibles ampliaciones futuras
del equipo.
PALABRAS CLAVES
Historia Clnica Electrnica, HIS, Sistema de energa de respaldo, Medicarro.
Aprobado con mencin: X

DEDICATORIA
A mis Padres, por su compaa, apoyo, constancia, ejemplo, amor, confianza, consejos y
solidaridad durante todo el camino transitado; por ensearme que en la vida no hay tiempo, ni
distancias mientras se ama, ni dificultades que no puedan superarse, les debo mi alma.
A mi Abuelita, por toda su dulzura, dedicacin y entrega; sus recuerdos son mis tesoros, sus
palabras son mi sabidura y su corazn es mi amor.
A mi Hermano y mi Hermanita, por ser las estrellitas en mi cielo, el horizonte que sueo
alcanzar, gracias por ensearme todo lo maravilloso que puede ser un ser humano, por ser mis
amigos, mi todo, gracias por existir.
A Clavito, por ser tan especial y transmitir tanta alegra.
A Gysvier, por ser mi angelito de la guarda, siempre a mi lado; por ser luz, magia, msica,
color y felicidad, gracias por permitirme vivir todo eso.
A mis Amigos, en especial a Andrs, Carlos y Pedro, por recordarme que siempre existen las
sonrisas y que con ellas podemos conquistar nuestros sueos.
A todos mis Profesores, que con su esfuerzo y tesn me ensearon que es posible construir un
mundo de excelencia, justicia, libertad, tolerancia, estudio, trabajo, constancia y amor.
AGRADECIMIENTOS
Al Profesor Ricardo Silva, por su apoyo incondicional.

Al Profesor Luis Suberviola e Ingeniero Miguel Cova, por su invaluable asesora.
A los que directa e indirectamente me ayudaron a realizar mi pasanta.
NDICE GENERAL
________________________________________________________________________
NDICE GENERAL
CAPITULO I:
INTRODUCCIN _____________________________________________ 1
1.1.
Planteamiento del problema ___________________________________________________ 1
1.2.
Descripcin del Proyecto ______________________________________________________ 2
1.3.
Antecedentes ________________________________________________________________ 3
1.4.
Objetivos ___________________________________________________________________ 5
1.4.1. Objetivo General ________________________________________________________________ 5
1.4.2. Objetivos Especficos ____________________________________________________________ 5
1.5.
Alcance ____________________________________________________________________ 6
1.6.
Limitaciones ________________________________________________________________ 7
1.7.
Estructura del Informe _______________________________________________________ 7
CAPITULO II: FUNDAMENTOS _____________________________________________ 9

2.1.
Sistema Hospitalario de Venezuela______________________________________________ 9

2.1.1. Leyes y normativas ligadas al Sistema Hospitalario de Venezuela __________________________ 9
2.1.2. Estructura del Sistema Hospitalario de Venezuela _____________________________________ 10
2.1.2.1. Nivel de Atencin Tipo I _____________________________________________________ 10
2.1.2.2. Nivel de Atencin Tipo II ____________________________________________________ 11
2.1.2.3. Nivel de Atencin Tipo III____________________________________________________ 12
2.1.3. Registro Mdico _______________________________________________________________ 12
2.1.3.1. Historias Mdicas __________________________________________________________ 12
2.1.3.2. KARDEX: Dispositivo de Registro Mdico ______________________________________ 15
2.2.
Referencia de Centro de Salud Asistencial ______________________________________ 15

2.2.1. Hospital Militar Dr. Carlos Arvelo _______________________________________________ 15
2.2.2. Estructura y Funcionamiento de Entorno Hospitalario __________________________________ 16
2.2.2.1. Servicio de Emergencia ______________________________________________________ 16
2.2.2.2. Servicio de Admisin _______________________________________________________ 17
2.3.
Conceptos bsicos de Registros Mdicos Electrnicos adaptados a Sistemas de Informacin

__________________________________________________________________________ 23
2.3.1. Historia Mdica Electrnica ______________________________________________________ 23
2.3.2. Diseo de un Sistema de Registro Mdico Electrnico _________________________________ 23
Universidad Simn Bolvar
NDICE GENERAL
ii
________________________________________________________________________
2.3.2.1. Requerimientos ____________________________________________________________ 23
2.3.2.2. Anlisis / Diseo ___________________________________________________________ 24
2.3.2.3. Desarrollo ________________________________________________________________ 24
2.3.2.4. Pruebas___________________________________________________________________ 25
2.3.2.5. Produccin / Mantenimiento __________________________________________________ 25
2.3.3. Estndar HL7 _________________________________________________________________ 25
2.4.
Requerimientos y lineamientos de Desarrollo e Implementacin de Software medico en
Venezuela ______________________________________________________________________ 26
2.4.1. Plan Nacional de Migracin a Software Libre ________________________________________ 26
2.5.
Herramientas disponibles para Desarrollo de Registros Mdicos Electrnicos adaptados a
Sistemas de Informacin __________________________________________________________ 27

2.5.1. Desarrollo de Aplicaciones Web ___________________________________________________ 27
2.5.1.1. PHP _____________________________________________________________________ 27
2.5.1.2. JSP: Java Server Pages ______________________________________________________ 28
2.5.1.3. ASP: Active Server Pages ____________________________________________________ 29
2.5.1.4. Ruby on Rails _____________________________________________________________ 30
2.5.2. Desarrollo de Base de Datos ______________________________________________________ 30
2.5.2.1. MySQL __________________________________________________________________ 30
2.5.2.2. Oracle____________________________________________________________________ 31
2.5.2.3. PostgreSQL _______________________________________________________________ 31
2.6.
Revisin de Sistemas de Registros Mdicos Electrnicos disponibles _________________ 32

2.6.1. OpenHis _____________________________________________________________________ 32
2.6.2. Proyecto Red-HL7 Universidad Simn Bolvar _______________________________________ 33
2.6.3. Care2x _______________________________________________________________________ 34
2.7.
Conceptos bsicos de Redes de Transmisin de Datos para Sistemas de Registros Mdicos
Electrnicos en Venezuela _________________________________________________________ 35

2.7.1. Arquitectura Cliente - Servidor ____________________________________________________ 35
2.7.1.1. Sockets ___________________________________________________________________ 36
2.7.2. Red de datos CANTV ___________________________________________________________ 37
2.7.2.1. Tipos de Conexin y Acceso __________________________________________________ 37
2.8.
Sistema de Energa de Respaldo _______________________________________________ 39

2.8.1. Sistemas de alimentacin de respaldo para cargas crticas _______________________________ 39
2.8.2. Confiabilidad __________________________________________________________________ 40
2.8.3. Configuraciones Tpicas _________________________________________________________ 41
2.8.4. Bateras estacionarias. ___________________________________________________________ 46
NDICE GENERAL
iii
________________________________________________________________________
2.8.4.1. Operacin y caractersticas ___________________________________________________ 46
2.8.4.2. Capacidad ________________________________________________________________ 52
2.8.4.3. Seleccin y dimensionamiento de bateras. _______________________________________ 55
2.8.5. Rectificadores-cargadores de bateras _______________________________________________ 55
2.8.5.1. Caractersticas y dimensionamiento ____________________________________________ 55
2.8.5.2. Configuraciones redundantes __________________________________________________ 56
2.8.6. Sistemas de Proteccin __________________________________________________________ 57
2.8.6.1. Breakers __________________________________________________________________ 57
2.8.6.2. Low Voltage Disconnect LVD ________________________________________________ 58
CAPITULO III: DISEO Y DESARROLLO DEL MEDICARRO ___________________ 59

3.1.
Requerimientos_____________________________________________________________ 59
3.1.1. Hardware _____________________________________________________________________ 59
3.1.2. Software _____________________________________________________________________ 59
3.1.3. Operatividad __________________________________________________________________ 60
3.1.4. Anlisis de Requerimientos _______________________________________________________ 60
3.2.
MEDICARRO: Estructura General ___________________________________________ 61

3.2.1. Seleccin de configuracin del Sistema de Energa de Respaldo __________________________ 61
3.2.2. Seleccin de equipos de Computacin ______________________________________________ 63
3.2.3. Seleccin de equipos de Sistema de Energa de Respaldo _______________________________ 67
3.2.4. Seleccin de Sistema de Registro Mdico Electrnico __________________________________ 77
3.2.5. Adaptaciones propuestas al Sistema de Registro Mdico Electrnico ______________________ 77
3.2.6. Seleccin de la Estructura Fsica ___________________________________________________ 78
3.2.7. Adaptaciones propuestas a la Estructura Fsica________________________________________ 79
3.2.7.1. Diseo estructural del Medicarro _______________________________________________ 81
3.2.7.1.1.
Mdulo Superior _______________________________________________________ 81
3.2.7.1.2.
Mdulo de Computacin _________________________________________________ 83
3.2.7.1.3.
Mdulo Energa de Respaldo _____________________________________________ 83
CAPITULO IV: FUNCIONAMIENTO DEL MEDICARRO ________________________ 84

CAPITULO V: PLAN DE ASISTENCIA TCNICA DEL MEDICARRO ____________ 87
5.1.
Procedimiento de Reporte y Seguimiento de Fallas _______________________________ 87
5.2.
Solicitud de Servicio _________________________________________________________ 87
5.3.
Niveles de Escalamiento de Fallas _____________________________________________ 88
5.4.
Plan de Asistencia Tcnica de Nivel Fsico del Medicarro _________________________ 88

NDICE GENERAL
iv
________________________________________________________________________
5.5.
Plan de Asistencia Tcnica de Nivel de Aplicacin del Medicarro ___________________ 90
CAPITULO VI: MS ALL DEL MEDICARRO ________________________________ 92

CAPITULO VII: ESTUDIO ECONMICO ____________________________________ 94
7.1.
Estudio de Costos del Proyecto ________________________________________________ 94
7.2.
Relacin Costo Beneficio _____________________________________________________ 96
CAPITULO VIII: CONLUSIONES Y RECOMENDACIONES ___________________ 103

8.1.
Conclusiones ______________________________________________________________ 103
8.2.
Recomendaciones __________________________________________________________ 104
CAPITULO IX: REFERENCIAS BIBLIOGRFICAS ___________________________ 105

CAPITULO X: ANEXOS __________________________________________________ 107
10.1 Formato 1_________________________________________________________________ 108
10.2 Formato 2_________________________________________________________________ 111
10.3 Formato 3_________________________________________________________________ 113
10.4 Formato 4_________________________________________________________________ 115
10.5 Formato 5_________________________________________________________________ 117
10.6 Formato 6_________________________________________________________________ 119
10.7 Formato 7_________________________________________________________________ 126
10.8 Formato 8_________________________________________________________________ 128
10.9 Formato 9_________________________________________________________________ 130
10.10 Formato 10_______________________________________________________________ 132
10.11 Sockets en PHP____________________________________________________________134
10.12 Formato de Historia Clnica Digital Propuesta__________________________________ 137
NDICE DE TABLAS
________________________________________________________________________
NDICE DE TABLAS
Tabla 1.
Implementacin de un Sistema de Historias Clnicas Electrnicas en India __ 4
Tabla 2.
Voltaje Nominal de batera de Plomo-cido __________________________ 50
Tabla 3.
Requerimientos de carga para Sistema de Respaldo de Energa ___________ 67
Tabla 4.
Equipos de Sistema de Respaldo ____________________________________ 76
Tabla 5.
Lista de General chequeo de problemas de nivel 1 y 2 del fallas ___________ 89
Tabla 6.
Equipos necesarios para implementar el diseo del Medicarro ___________ 95
Tabla 7.
Costo del Medicarro ______________________________________________ 95
Tabla 8.
Inversin del Medicarro _________________________________________ 100
Tabla 9.
Comparacin de Costos __________________________________________ 101
vi
NDICE DE FIGURAS
________________________________________________________________________
NDICE DE FIGURAS
Figura 1.
OpenHIS_______________________________________________________ 32
Figura 2.
Red-HL7 _______________________________________________________ 33
Figura 3.
Care2x HIS ____________________________________________________ 35
Figura 4.
Transmisin ADSL ______________________________________________ 37
Figura 5.
Distribucin de Servicios en ADSL __________________________________ 38
Figura 6.
Sistema paralelo en operacin normal _______________________________ 41
Figura 7.
Sistema paralelo durante falla de red elctrica de alimentacin ___________ 42
Figura 8.
Redundancia de Bateras __________________________________________ 42
Figura 9.
Sistema de respaldo para varias cargas ______________________________ 43
Figura 10.
Sistema de Respaldo en paralelo para cargas AC ______________________ 43
Figura 11.
Sistema Conmutado en modo normal ________________________________ 44
Figura 12.
Sistema Conmutado en modo de descarga ____________________________ 45
Figura 13.
Sistema de Respaldo Conmutado para cargas AC ______________________ 45
Figura 14.
Constitucin bsica de una batera __________________________________ 46
Figura 15.
Profundidad de Ciclado ___________________________________________ 47
Figura 16.
Batera durante operacin _________________________________________ 51
Figura 17.
Requerimiento Energtico vs. Tiempo de Autonoma ___________________ 52
Figura 18.
Capacidad de batera _____________________________________________ 53
Figura 19.
Envejecimiento de Batera de Plomo - cido __________________________ 54
Figura 20.
Redundancia Rectificadores _______________________________________ 56
Figura 21.
Sistema de respaldo con Breakers ___________________________________ 57
Figura 22.
Sistema de respaldo con Low Voltage Disconnect ______________________ 58
NDICE DE FIGURAS
vii
________________________________________________________________________
Figura 23.
Funcionamiento general del Medicarro ______________________________ 61
Figura 24.
Configuracin de Sistema de Computacin ___________________________ 67
Figura 25.
Requerimientos del Medicarro _____________________________________ 68
Figura 26.
Requerimientos del Medicarro _____________________________________ 69
Figura 27.
Dimensiones Batera UPS 12540 MR _______________________________ 71
Figura 28.
Dimensiones de Rectificador _______________________________________ 73
Figura 29.
Diseo de Medicarro _____________________________________________ 80
Figura 30.
Mdulo Superior del Medicarro ____________________________________ 81
Figura 31.
Pantalla del Medicarro Posicin I __________________________________ 82
Figura 32.
Pantalla del Medicarro Posicin II __________________________________ 82
Figura 33.
Mdulo de Computacin __________________________________________ 83
Figura 34.
Mdulos de Energa de Respaldo y Computacin ______________________ 83
Figura 35.
Funcionamiento del Medicarro_____________________________________ 86
Figura 36.
Modalidad de Listas de Trabajo ____________________________________ 93
viii
NDICE DE FOTOS
________________________________________________________________________
NDICE DE FOTOS
Foto 1.
Bsqueda de la Historia Clnica. Parte I _____________________________ 20
Foto 2.
Bsqueda de la Historia Clnica. Parte II ____________________________ 20
Foto 3.
Bsqueda de la Historia Clnica. Parte III ____________________________ 21
Foto 4.
Bsqueda de la Historia Clnica. Parte IV ____________________________ 21
Foto 5.
Bsqueda de la Historia Clnica. Parte V _____________________________ 22
Foto 6.
LinCon-8000 ___________________________________________________ 63
Foto 7.
Tarjeta D201GLY de INTEL _______________________________________ 64
Foto 8.
Conector de 12 V DC a Conector ATX _______________________________ 65
Foto 9.
Adaptador de Disco Flash _________________________________________ 65
Foto 10.
Memoria RAM __________________________________________________ 66
Foto 11.
Medicarro I ____________________________________________________ 79
CAPITULO I: INTRODUCCIN
________________________________________________________________________
1.1. PLANTEAMIENTO DEL PROBLEMA
En el marco de la modernizacin y dotacin de herramientas tecnolgicas al sector de salud
del pas, el Centro de Innovacin Tecnolgica (CENIT), adscrito al Ministerio del Poder
Popular para Ciencia y Tecnologa, se encuentra realizando un conjunto de proyectos
orientados al desarrollo de soluciones de ingeniera, que permitan brindar atencin efectiva y
de calidad a la poblacin, en los centros de atencin hospitalarios. As como contar con
herramientas de prevencin, seguimiento y control de enfermedades.
En este sentido, se ha prestado vital importancia a todo lo referente al manejo de Historias
Clnicas dentro de las instituciones, ya que uno de los mayores problemas de salud en la
actualidad, es la enorme cantidad de historias mdicas en papel y acetato que deben ser
archivadas, manipuladas y procesadas. Como consecuencia de ello, se complican los
procedimientos posteriores: bsqueda de la historia para anexar los exmenes realizados,
control y monitoreo de pacientes; se obstaculizan los procesos de planificacin y estudio
estadstico, que se realizan con el fin de destinar los recursos a la prevencin de enfermedades
y causas consultadas que as lo requieran.
Adicionalmente, resulta importante destacar que cada institucin lleva su registro de
manera particular, es decir, sin comunicacin con el resto de los centros de salud, lo que
imposibilita poder atender eficientemente a un paciente de acuerdo a sus antecedentes cuando
llegue a una institucin donde no haya sido atendido previamente.
De esa forma, dada la importancia que representa el sistema de registro de historias
clnicas, se presenta como punto fundamental el diseo de un equipo para el manejo de
historias mdicas electrnicas, a travs del cual se pueda desplegar un sistema de registro y
acceso a la informacin de un paciente desde la institucin que le va a prestar atencin.
________________________________________________________________________
1.2. DESCRIPCIN DEL PROYECTO
El sistema de registro medico actual se encuentra en evolucin hacia un sistema mucho ms

eficiente de nueva generacin, donde se puede llevar un registro nico de cada paciente,
acorde con las caractersticas del sistema hospitalario existente en el pas, los avances
tecnolgicos en el rea y lineamientos gubernamentales. Este planteamiento ofrece mltiples
ventajas entre las cuales destacan:
Optimizacin del servicio de atencin medica.
Carcter universal de la Historia Clnica: cada ciudadano pertenecer a un nico registro.
Los pacientes podrn ser atendidos de forma eficiente, adecuada y personalizada en una
institucin de salud, de acuerdo a sus antecedentes; sin necesidad de que tengan que
comunicarlos cada vez que visiten una institucin mdica.
Monitoreo a nivel estadstico de casos atendidos: permitiendo correlacionar perfiles de los
casos (edad, sexo, ocupacin, entre otros) con causas consultadas, tanto con fines
acadmicos y de investigacin como para destinar recursos, atencin, campaas, entre
otros a las enfermedades que as lo requieran.
Enriquecimiento tecnolgico y social: las instituciones de salud podrn ofrecer tecnologa
actualizada y acorde con los avances en el rea, como consecuencia de ello, se lograr
incentivar y fortalecer la familiarizacin tecnolgica en el personal que labora en los
centros asistenciales; contribuyendo con el proceso de formacin de profesionales
integrales, dispuestos a emplear herramientas tecnolgicas en el cuidado de pacientes. Todo
esto favorece la constitucin de un sistema hospitalario de mayor calidad.
Reduccin de costos y beneficio ambiental: la reduccin de costos asociados a la papelera
empleada para el registro, ha sido una de las mayores motivaciones, ya que con ello no slo
se puede disponer de ms recursos para otras reas, sino que tambin se puede disminuir el
impacto negativo sobre el medio ambiente, causado por el empleo de la enorme cantidad de
fichas.
________________________________________________________________________
Es por ello, que el CENIT, busca la aplicacin de nuevas tecnologas orientadas a responder
oportunamente a las necesidades y requerimientos del sistema hospitalario y se propone el
diseo de un equipo que pueda ser empleado como punto de acceso para el manejo de historias
clnicas, permitiendo llevar un registro mucho ms eficiente que el actual. Se estableci un
convenio entre el CENIT y la Universidad Simn Bolvar (USB) a travs de la Unidad de
Gestin de Tecnologa en Salud (UGTS), unidad operativa de la Fundacin de Investigacin y
Desarrollo de la Universidad Simn Bolvar (FUNINDES).
La UGTS funciona como unidad operativa de FUNINDES, la cual se encarga de vincular
las capacidades cientficas y tecnolgicas de la USB con el sector productivo del pas, en este
sentido, la UGTS desde sus inicios se ha destinado a llevar a cabo, en forma integral y
exclusiva, la ejecucin de proyectos de ingeniera en el rea de salud. En la actualidad, se
encuentra desarrollando diversos proyectos entre los que se pueden mencionar: el desarrollo
de una plataforma de regeneracin celular mediante estimulacin elctrica y el desarrollo de
un dispensador automtico de tabletas.
De esa manera, la UGTS fue la responsable del diseo del primer prototipo de equipo para
el manejo de historias clnicas, evaluando diversas soluciones de software de registro
electrnico. Para ello, se consideraron diversos factores como: la estructura y funcionamiento
hospitalario, soluciones comerciales disponibles y experiencias previas relacionadas con el
planteamiento.
1.3. ANTECEDENTES
Existen numerosas experiencias de soluciones para el manejo de historias clnicas a nivel
mundial, todas orientadas a brindar una mejor calidad de atencin. Particularmente se pueden
mencionar dos experiencias, la primera de ellas se refiere a la implementacin de un registro
mdico electrnico en el Hospital Alemn de Buenos Aries.
________________________________________________________________________
Este proyecto logr incorporar aproximadamente 500 profesionales, 100% de los

profesionales de la institucin, en el trmino de nueve meses, cumpliendo ampliamente las
expectativas y los objetivos marcados al comienzo. Actualmente, las 36200 consultas
ambulatorias mensuales del hospital, se hacen a travs del sistema de historias clnicas
electrnicas. [1]
Esta experiencia resulta sumamente importante, ya que indica que el personal profesional
de una institucin de salud puede familiarizarse con el sistema de historias clnicas
electrnicas, manteniendo cifras elevadas de atencin.
La segunda experiencia considerada, fue la implementacin de un sistema de historias
clnicas electrnicas en el Hospital de ATA, ubicado en Jamshedpur, India, donde se
obtuvieron los siguientes resultados [2]:
Indicador
Antes de la
Despus de la
implementacin del
implementacin del
Proyecto
Proyecto
10 minutos
5 minutos
Tiempo de espera en
Admisin
Beneficios
Reduccin
tiempo
que
del
debe
esperar un paciente
Inventario de
2,5 meses
1,7 meses
registros
Cierre mensual
Mejor desempeo de
Institucin de Salud
3 das
Inmediato
Mejor desempeo de
Institucin de Salud
Tabla 1. Implementacin de un Sistema de Historias Clnicas Electrnicas en India
Todo esto evidencia el impacto positivo que puede causar la implementacin de un sistema
de historias clnicas electrnicas en la atencin mdica.
________________________________________________________________________
En cuanto a la estructura fsica del equipo a disear, una experiencia de inters proviene
de la compaa DELL, la cual incorpor a sus soluciones comerciales un equipo destinado a
las instituciones asistenciales (Mobile Medication Cart with locking Side Bin), para que el
personal de enfermera pudiera distribuir los medicamentos para cada paciente con ms
facilidad. El equipo viene dado bsicamente por una laptop, sobre una estructura mvil, con
compartimientos para los medicamentos y el costo es de 3.229,99 $ 6.944,48 Bs.F. [3]
1.4. OBJETIVOS
1.4.1. Objetivo General

El objetivo del proyecto consisti en el diseo del prototipo de un equipo capaz de
manejar historias clnicas electrnicas en el Sistema Hospitalario Venezolano.
1.4.2. Objetivos Especficos

El logro de este objetivo general se alcanz mediante el cumplimiento de los siguientes
objetivos especficos:
Estudio de las normativas, estructura y funcionamiento del sistema hospitalario en
Venezuela.
Establecimiento de los procedimientos y herramientas para la implementacin de un
sistema de registro medico electrnico.
Estudio y anlisis de los requerimientos para el diseo del equipo de historias clnicas en el
Sistema Hospitalario Venezolano.
Establecimiento del diseo general del equipo de manejo de historias clnicas, respondiendo
a los requerimientos, disponibilidad de equipos a implementar y factores financieros.
Propuesta de funcionamiento del equipo de manejo de historias clnicas adaptado a los
procedimientos tpicos de una institucin de salud.
________________________________________________________________________
Durante la ejecucin del proyecto, se necesit llevar a cabo un conjunto de objetivos extras
(fuera del alcance inicial) que permitieron alcanzar un mayor dominio y mbito global del
proyecto. Tales objetivos logrados que se encuentran fuera del alcance inicial del proyecto
fueron:
Propuesta de formato de la historia mdica electrnica para el Sistema Hospitalario de
Venezuela.
Estudio y recopilacin de las principales soluciones comerciales para la seleccin de
equipos.
Propuesta de software comercial y sus posibles adaptaciones.
Diseo y dimensionamiento de un sistema de energa de respaldo.
Realizacin de Ingeniera de detalle en el diseo de la estructura externa para el equipo de
manejo de historias clnicas.
Propuesta de futuras ampliaciones al equipo de manejo de historias clnicas.
Generacin de un Plan de Asistencia Tcnica que permita determinar de manera rpida y
oportuna, las fallas que puedan ocurrir en el equipo de manejo de historias clnicas y los
procedimientos a seguir para su resolucin.
1.5. ALCANCE
La concepcin de una solucin para el manejo de historias clnicas adaptado al sistema
hospitalario de Venezuela, rompe fuertemente los paradigmas y de inmediato nos define una
serie de posibilidades de produccin de aplicaciones cientficas, similares como parte de la
produccin nacional.
El diseo del equipo contempl como modo piloto las reas de emergencia y admisin de
una institucin de salud, tomando en cuenta que el diseo obtenido puede ser despus
escalable de forma modular al resto de las reas de un centro de salud tpico, bajo la ejecucin
de otro proyecto.
________________________________________________________________________
Igualmente, por tratarse del diseo de un prototipo no se tomaron en cuenta el conjunto de

consideraciones legales de las que son objeto las historias clnicas, ya que eso formara parte
de adaptaciones posteriores.
Por ltimo, resulta importante resaltar que los programas y sistemas de gestin empleados,
representan sistemas de registro dispuestos para establecer el primer prototipo de equipo de
manejo de historias clnicas, pruebas de funcionamiento y visin del sistema global, sin
embargo, no representan por el momento la versin final o ideal del sistema de registro nico,
ya que estas decisiones provienen de entes gubernamentales.
1.6. LIMITACIONES
La principal limitacin result ser la escasez de dispositivos y maquinarias al alcance para
concretar el diseo del equipo de manejo de historias clnicas, que aunque pudo llevarse a
cabo exitosamente, requiri una considerable inversin de tiempo haciendo numerosas
diligencia, visitas y consultas en la bsqueda de apoyo y contactos, todo esto debido a que se
trata de un proyecto sin precedentes en el pas, considerando su alcance e impacto.
Adicionalmente, se experimentaron diversas dificultades en cuanto a la asignacin de
recursos econmicos por parte de los organismos comprometidos con el proyecto, dificultando
as, la elaboracin del diseo del equipo.
1.7. ESTRUCTURA DEL INFORME

La estructura del siguiente informe es como se muestra a continuacin:
En el Captulo II, se detallan todos los conceptos bsicos necesarios, para que el lector
pueda entender de manera global la complejidad, tecnologas y conceptos involucrados en
el proyecto.
________________________________________________________________________
En el Captulo III, se detalla la necesidad de desarrollar el diseo de un equipo de historias

clnicas, as como los diversos procedimientos y mdulos necesarios para llevarlo a cabo.
En el Captulo IV, se propone el procedimiento de atencin con la implementacin del
equipo de manejo de historias clnicas, tomando en consideracin el protocolo de atencin
actual, as como el sistema de registro mdico electrnico sugerido.
En el Captulo V, se muestra un resumen del plan de asistencia tcnica para el equipo de
manejo de historias clnicas, se consideran los problemas ms comunes y el diagnstico
correspondiente en materia de fallas de Hardware y Software.
En el Captulo VI, se describen las distintas facetas que puede adoptar el equipo de historias
clnicas en adaptaciones futuras, incorporando otras modalidades de funcionalidad, alcance
y equipos.
En el Captulo VII, se hace un completo estudio econmico del proyecto, presentando la
relacin costo beneficio con la ejecucin del mismo.
En el Captulo VIII, se muestran las principales conclusiones y recomendaciones para este
proyecto.
CAPITULO II: FUNDAMENTOS

________________________________________________________________________
CAPITULO II:
FUNDAMENTOS
2.1. SISTEMA HOSPITALARIO DE VENEZUELA
2.1.1. Leyes y normativas ligadas al Sistema Hospitalario de Venezuela

La salud viene dada por el estado de completo bienestar fsico, mental y social, no
solamente la ausencia de afecciones o enfermedades, en este sentido, en Venezuela se han
formulado diversas leyes y normativas,
que garantizan a la salud como derecho social
fundamental. Especficamente, la Constitucin de la Repblica Bolivariana de Venezuela

Publicada en 1999, en el Ttulo III, Captulo V de los Derechos Sociales y de las Familias, en
sus artculos 83, 84 y 85, garantiza que la salud es un derecho social fundamental, obligacin
del Estado, como parte del derecho a la vida. [4]
Igualmente, en la constitucin se establece que el Estado promover y desarrollar polticas
orientadas a elevar la calidad de vida, el bienestar colectivo y el acceso a los servicios, esto
debido a que todas las personas tienen derecho a la proteccin de la salud.
El financiamiento del sistema pblico nacional de salud es obligacin del Estado,
promoviendo y desarrollando una poltica nacional de formacin de profesionales, tcnicos e
industria nacional para la salud, en coordinacin con las universidades y los centros de
investigacin e innovacin.
El Ministerio del Poder Popular para la Salud, se encuentra a cargo de la rectora y gestin
del sistema pblico nacional de salud, a travs del diseo, implementacin y supervisin de
estrategias, que contribuyen al fortalecimiento e integracin de los diversos entes prestatarios
del servicio y atencin en salud, con la finalidad de mejorar la calidad de vida y bienestar de la
poblacin.
10

________________________________________________________________________
De esa manera, el sistema pblico nacional de salud dar prioridad a la promocin de la

salud y a la prevencin de las enfermedades, garantizando tratamiento oportuno y
rehabilitacin de calidad.
En 2006, se decret el Reglamento Orgnico del Ministerio de Salud, de esa manera se
establecieron diversas normativas, de supervisin, control y evaluacin fundamentada en la
poltica de salud vigente, orientados a la atencin de necesidades sociales, bajo un enfoque
participativo, a travs de la comunidad organizada, basados en los principios de equidad,
solidaridad y universalidad. [5]
En particular, en el Captulo III del despacho del Viceministro de Redes de Servicios de
Salud, en su Artculo 18, el Ministerio del Poder Popular para la Salud debe promover el
desarrollo de modelos de gestin que favorezcan la atencin integral de la poblacin, as como
fomentar cambios e innovaciones en la organizacin, gestin y funcionamiento de los
servicios de salud, de acuerdo a los avances tcnicos y cientficos.
En vista de lo amplio del Sistema Hospitalario en Venezuela, ste fue estructurado de
acuerdo a niveles de atencin: I, II y III, acorde con su complejidad, estructura y ubicacin.
Cabe destacar que la estructura organizativa de los diversos niveles de atencin en salud, se
encuentran estructurados de manera que permitan la implementacin de polticas y estrategias
que optimicen su funcionamiento, aumentando su capacidad resolutiva, consolidacin y
alcance, permitindoles as prestar un servicio conforme con los avances tecnolgicos.
2.1.2. Estructura del Sistema Hospitalario de Venezuela

2.1.2.1. Nivel de Atencin Tipo I
El primer nivel de atencin a la salud del Sistema Pblico Nacional de Salud, tiene como
objetivo garantizar el acceso a los servicios de salud a la poblacin, sin ningn tipo de
11

________________________________________________________________________
discriminacin, mediante un modelo de gestin de salud integral orientado a dar respuesta

inmediata a las necesidades sociales de salud de la poblacin.
Este nivel, representa la puerta de entrada natural al Sistema Pblico Nacional de Salud y el
punto de inicio de la Red Asistencial.
Adicionalmente, se promueve la coordinacin del centro de atencin en salud del primer
nivel en la red asistencial pblica, con otros dentro del mismo nivel y con los otros niveles de
la red, as como el monitoreo, implantacin y evaluacin de modelos de gestin que respondan
a las necesidades sociales, mediante la organizacin y participacin de las comunidades.
2.1.2.2. Nivel de Atencin Tipo II

El segundo nivel de atencin a la salud del Sistema Pblico Nacional de Salud, tiene como
objetivo garantizar de manera oportuna, eficaz y eficiente la atencin integral y el diagnstico
de las diversas patologas que son de alta incidencia en la poblacin.
El acceso a este nivel es a travs del sistema de referencias y contrarreferencias de los
otros niveles de atencin o a travs de las emergencias, en aquellos centros de II nivel que
tengan este servicio.
En este sentido, cada establecimiento del segundo nivel de atencin atender a un nmero
determinado de establecimientos del primer nivel y a una poblacin determinada en el primer
nivel.
Adicionalmente, se promueve la coordinacin del centro de atencin en salud del segundo
la red, organizando y manteniendo actualizado los procedimientos de referencia y
contrarreferencia para el ingreso y egreso de los usuarios en la red ambulatoria especializada
en salud.
12

________________________________________________________________________
2.1.2.3. Nivel de Atencin Tipo III
El tercer nivel de atencin en salud del Sistema Pblico Nacional de Salud con el objeto de
coordinar y supervisar la atencin de las patologas y otras situaciones que no puedan ser
resueltas en los otros niveles de atencin y las que requieran hospitalizacin para su
tratamiento.
El acceso a este nivel ser a travs del sistema de referencias y contrarreferencias de los
otros niveles de atencin o a travs de las emergencias en aquellos centros de tercer nivel que
tengan este servicio.
Resulta relevante mencionar que cada establecimiento del tercer nivel de atencin en salud
atender a un nmero determinado de establecimientos del segundo nivel y a una poblacin
tambin determinada en el primer y segundo nivel nivel, con la excepcin de los Hospitales de
Especialidades, los Hospitales Tipo IV y los Centros Diagnsticos de Alta Tecnologa, los
cuales atendern a la poblacin que lo requiera, con la debida referencia.
Adicionalmente, se promueve la coordinacin del centro de atencin en salud del tercer
la red, procurando los procedimientos de referencia y contrarreferencia para el ingreso y
egreso de los usuarios del nivel, y garantizar con esto, que las personas atendidas tengan
seguimiento de su situacin de salud en el primer nivel de atencin.
2.1.3. Registro Mdico

2.1.3.1. Historias Mdicas
Con el objetivo de brindar una atencin mdica de calidad, las instituciones deben llevar un
registro mdico, a travs de la Historia Clnica, esto debido a que la asistencia de los pacientes
13

________________________________________________________________________
tanto hospitalizados como ambulatorios, genera una serie de informacin mdica y

administrativa sobre los mismos.
En este sentido, se constituye la historia clnica como un documento privado, obligatorio y
sometido a reserva, en el cual se registran de manera cronolgica las condiciones de salud del
paciente, los actos mdicos y los dems procedimientos ejecutados por el equipo de salud que
interviene en su atencin. De esa forma, debe encontrarse disponible en cualquier momento en
el que resulte necesaria. [6]
El propsito de la Historia Clnica es en primer lugar servir como evidencia documentada
sobre el curso de la enfermedad y tratamiento del paciente, lo que puede conducir en su
utilizacin como documento legal, en aquellas situaciones jurdicas que as lo requieran. Por
otro lado, proporciona un medio de comunicacin entre el mdico y otros profesionales, de
manera que puede servir como instrumento para planificar la atencin al paciente y contribuir
a que sta sea continua.
De igual manera, la historia clnica provee informacin para usos de investigacin y
docencia, y sirve como base para la revisin, estudio y evolucin de la calidad de atencin
prestada al paciente.
Para cumplir estas funciones, el registro mdico debe ser realizado con rigurosidad,
relatando todos los detalles necesarios, con un formato unificado y letra legible, igualmente, la
historia clnica de un paciente debe reunir la informacin de los aspectos cientficos, tcnicos
y administrativos relativos a la atencin mdica, en sus diferentes fases, abordando aspectos
biolgicos, psicolgicos y sociales.
Los formularios integran la historia clnica y sin importar el tipo de caso, son clasificados
en tres grupos principalmente:
14

________________________________________________________________________
La forma en blanco: se limita a tener impreso el formato para los datos de identificacin e
informacin social, quedando en blanco el resto, para luego ser llenado a libre criterio por
el mdico.
La forma tabulada: adems de tener impreso el formato de los datos de identificacin e
informacin social, se encuentran cada uno de los detalles que deben de ser investigados
durante la atencin mdica, con suficiente espacio para llenar la respuesta del caso.
La forma semi tabulada: se trata de un formato mixto que rene las ventajas de los formatos
en blanco y tabulados.
De manera general, la estructura de la historia clnica se conforma por tres secciones:

Seccin de Identificacin: debe contener suficiente informacin sobre los sntomas
subjetivos de consultas, historia familiar y personal, historia de la enfermedad actual.
Seccin Mdica: esta parte es importante desde el punto de vista cientfico, estos son los
resultados del examen fsico, diagnostico provisional, ordenes de exmenes y tratamiento.
Seccin de Enfermera: comprende las grficas de temperatura, pulso, respiracin,
frecuencia de evaluacin y tratamientos administrados segn la orden mdica escrita para el
paciente.
Los registros generados durante la atencin mdica deben almacenarse segn en secuencia
cronolgica en que ocurrieron, de esa manera, deben ser archivados a travs de la acumulacin
de documentos relativos a la atencin mdica del paciente, para su almacenamiento se dispone
de los siguientes mtodos:
Cronolgico Integrado: en este mtodo, los datos o informes son ordenados por fechas
sucesivas.
Cronolgico por Secciones: en este mtodo, se agrupan los informes o resultados
cronolgicamente por secciones o servicios.
15

________________________________________________________________________
Cabe destacar que en la actualidad, no existe un formato nico establecido para el registro y
seguimiento de pacientes dentro del sistema hospitalario de Venezuela, que aplique a todas las
instituciones, de esa forma, cada institucin y en consecuencia, cada nivel de atencin posee
su formato particular.
2.1.3.2. KARDEX: Dispositivo de Registro Mdico

El kardex es un sistema de registro y control empleado para el almacenamiento tradicional;
a travs de archivos. Su funcionamiento viene dado por la implementacin de ficheros, que
contienen informacin sobre la direccin especfica, mediante codificacin, de un documento
en particular dentro de un archivo. En consecuencia, el kardex es ampliamente empleado en
centros de atencin mdicos, para el almacenamiento de las historias clnicas.
En la actualidad, el kardex automatizado se fundamenta en una serie de sistemas
computacionales que cumplen esa misma funcin.
2.2. REFERENCIA DE CENTRO DE SALUD ASISTENCIAL
2.2.1. Hospital Militar Dr. Carlos Arvelo

Con el objetivo de proponer un sistema de manejo de historias clnicas, se necesit
evidenciar las caractersticas y procedimientos del registro medico en el rea de emergencia y
admisin, para ello, se realizaron sucesivas visitas al Hospital Militar Dr. Carlos Arvelo,
especficamente, en las secciones de informtica e historias clnicas.
El Hospital Militar Dr. Carlos Arvelo, tuvo sus inicios en el ao de 1953, con el nombre
de Hospital Militar Naval Antonio Jos de Sucre, que funcion en la esquina de Poleo, en
Caracas; en el ao 1960, fue trasladado a la avenida Jos ngel Lamas de San Martn, donde
se le nombr Hospital Central de las Fuerzas Armadas; pasado el tiempo, dicha institucin
16

________________________________________________________________________
recibi el nombre por el que hoy se le conoce, Hospital Militar Dr. Carlos Arvelo, en
reconocimiento al ilustre Prcer Medico de la gesta emancipadora.
La construccin de esta moderna edificacin, fue concebida y diseada con capacidad para
mil doscientas camas, para ello se tom en cuenta la
funcionalidad operativa y las
experiencias cientficas de grandes y reconocidos centros de salud situados en Europa y el

Continente Americano; de manera que esta institucin es un excelente acopio de informacin
relacionada con la estructura fsica y el funcionamiento modelo de un centro asistencial.
Actualmente, el Hospital Militar Dr. Carlos Arvelo se encuentra clasificado como un
hospital tipo IV dentro del sistema hospitalario, brindando as atencin a la poblacin en
general, con novecientas camas en funcionamiento y ms de cuarenta y tres especialidades,
con actividades de docencia e investigacin para un total de veintisiete postgrados.
En este sentido la institucin se encuentra plenamente comprometida con el avance y la
implementacin de nuevas herramientas que permitan brindar mejor atencin mdica, con
mayor valor tecnolgico y cientfico, promoviendo as, la bsqueda del conocimiento y
mejoras en la calidad de vida.
2.2.2. Estructura y Funcionamiento de Entorno Hospitalario

2.2.2.1. Servicio de Emergencia
En la seccin de emergencia se toman los datos del paciente que ha de ser atendido en el
servicio, a travs de una ficha destinada para este fin (ver Anexo 10.1.), solicitndole los datos
de identificacin, antecedentes, motivo de la consulta, examen fsico y diagnostico presuntivo.
En caso de que el paciente sea menor de edad, se le toman los datos personales del padre, la
madre o el representante.
17

________________________________________________________________________
Estos datos son escritos adicionalmente en el libro de control de admisin de emergencias,

la numeracin del mismo, cambia al final de cada turno, siempre empezando por el nmero
01, en este sentido, deben ir en orden cronolgico con fecha y hora de llegada de cada
paciente.
En caso de ser requerida alguna historia clnica, sta se solicita a la seccin de archivo a
travs de la seccin admisin en caso de que el paciente sea para hospitalizar.
Al final del turno, el personal tcnico realiza la estadstica de pacientes vistos por mdicos
y por afiliacin, al igual que el cierre del libro del turno correspondiente y entrega de fichas
en el archivo central (ver Anexo 10.2. 10.3. y 10.4.).
2.2.2.2. Servicio de Admisin

Esta seccin se responsabiliza por las acciones relacionadas con el ingreso, egreso de
pacientes y el correspondiente seguimiento durante su hospitalizacin. Mantiene el registro y
custodia de las historias clnicas del paciente de emergencias, para recolectar y procesar las
estadsticas de la institucin.
El procedimiento en cuanto a las historias clnicas es el siguiente:
Se reciben admisiones de pacientes que vienen por consulta externa y/o emergencia.
Por consulta externa el paciente se dirige a admisin con orden de ingreso entregada por el
mdico tratante, en momento, el tcnico de informacin de salud encargado verifica si el
paciente cumple con todos los requisitos exigidos por la institucin, si es afiliado y/o
familiar del mismo, en caso de ser un paciente no afiliado o proveniente del plan nacional
barrio adentro, se debe constatar autorizacin, firma y sello hmedo de la direccin del
establecimiento de salud que lo referencia (ver Anexo 10.5.).
Se interroga al paciente con el fin de conocer si posee historia clnica en el hospital, en caso
de no poseer, se procede a dar nmero de historia y a llenar la hoja Historia Clnica (ver
18

________________________________________________________________________
Anexo 10.6.) con los datos personales del paciente, nmero de historia asignada, cargo del
servicio que ingresa, habitacin y servicio asignado, hora de ingreso, diagnstico clnico,
firma del paciente y del tcnico que realiza el ingreso.
Si el paciente tiene historia clnica se procede a solicitar el complemento en la seccin de
archivo.
Luego se procede a realizar las seis fichas de ingreso (ver Anexo 10.7.) para ser distribuidas
de la siguiente forma: panel de hospitalizacin, ndice de paciente en la pared, boleta,
informacin, cuerpo y fichero para informacin; cada una de ellas deben llevar los datos
personales, servicio, habitacin, diagnostico, inciales del tcnico que elabor su ingreso.
El paciente es hospitalizado.
En esta seccin, se realizan las boletas de egreso de pacientes (ver Anexo 10.8.).
Resulta relevante mencionar que cada vez que culminan los turnos se realizan labores de
censo (ver Anexo 10.9. y 10.10.). Adicionalmente, se realizan labores de arreglos de historias
si estn repetidas.
Una vez que el paciente abandona el establecimiento de salud, la historia clnica se ordena
en la siguiente forma:
Orden de Admisin a Hospitalizacin.
Historia Clnica Parte I
Historia Clnica Parte II
Historia Clnica Parte III
Reporte de Consulta.
Laboratorio Clnico
Informa Radiolgico
Informe Electrocardiograma
Informe de otros exmenes auxiliares de diagnstico
Orden Preoperatorio
19

________________________________________________________________________
Hoja de Anestesia
Informe Quirrgico
Recuperacin
Informe Anatomo-Patolgico
Evolucin Medica
Ordenes Medicas
Evolucin Nutricional
Graficas
Evolucin Enfermera
Hoja de Medicamento
Control de Signos Vitales
Protocolo de autopsia
Boleta de Salida
Las historias clnicas se desincorporan en la institucin, siguiendo las recomendaciones

realizadas por la Organizacin Panamericana de la Salud, para ello se revisan las historias
clnicas cada diez aos. [7]
Los archivos se clasifican de la siguiente manera:
Archivo Activo: constituido por las historias frecuente.
Archivo Pasivo: se refiere a las historias desincorporadas por razones de antigedad o
cesanta en uso de los servicios prestados en la institucin. Sin embargo, se debe garantizar
la conservacin de los documentos que contiene, pues luego pueden ser requeridos por el
paciente o bien, para fines de inters cientfico.
Archivo Paralelo: se refiere a los documentos de boletas de emergencia y fichas de
prstamos.
20

________________________________________________________________________
El procedimiento de bsqueda de la historia clnica en la institucin es el siguiente:
Se emplea un kardex no automatizado, para el almacenamiento, clasificacin y control de

documentos dedicados al manejo de las fichas con el nmero de historia de los pacientes.
Foto 1. Bsqueda de la Historia Clnica. Parte I
Se presiona la primera letra del apellido del paciente a buscar.
Foto 2.
Bsqueda de la Historia Clnica. Parte II
21

________________________________________________________________________
Las bandejas de almacenamiento rotan hasta llegar a la letra correspondiente al apellido del
paciente a localizar
Foto 3. Bsqueda de la Historia Clnica. Parte III
Se debe buscar manualmente la ficha correspondiente al paciente, dicha ficha proporcionar

el nmero de historia
Foto 4. Bsqueda de la Historia Clnica. Parte IV
22

________________________________________________________________________
Para culminar el proceso, se ubica la historia del paciente en el archivo
Foto 5.
Bsqueda de la Historia Clnica. Parte V
De todo esto, se deduce que existe la necesidad de implementar un sistema de manejo de

historias clnicas ms eficiente y efectivo, con el que se pueda brindar una mayor calidad de
atencin mdica, ajustado a los protocolos establecidos.
Cabe destacar que las estadsticas referenciales no formales aportadas por los
profesionales, afirman que los equipos livianos y mviles instalados no son apropiados para la
institucin, por ser susceptibles al hurto o al dao intencional.
23

________________________________________________________________________
2.3. CONCEPTOS
BSICOS
DE
REGISTROS
MDICOS
ELECTRNICOS
ADAPTADOS A SISTEMAS DE INFORMACIN
2.3.1. Historia Mdica Electrnica

El registro mdico mediante sistemas informticos ofrece una solucin con mltiples
beneficios, que sustituye o reduce las labores de registros utilizando formularios en papel y
propone un sistema que facilita la integracin y continuidad de la asistencia mdica.
En este sentido, se realiza el registro y luego la informacin puede ser vista, ampliada y
modificada por el personal con los privilegios para ello, desde la unidad de computacin que
cuente con la conectividad adecuada, sin tener entonces que escribir numerosos formularios,
con los mismos datos, para distribuirlos a las diferentes unidades dentro de un centro
asistencial.
Los valores agregados ms significativos son el acceso y las ventajas en cuanto a la
seguridad y confidencialidad de la informacin del paciente, es ms segura que su equivalente
en papel, ya que la misma no estara custodiada por archivos convencionales, sino por
sistemas electrnicos, que pueden presentar un nivel de seguridad elevado, dependiendo de las
herramientas de programacin empleadas.
[8]
De esa forma, el complicado procedimiento de acceso a la historia clnicas, se ve

simplificado a la manipulacin de un equipo que tenga acceso al sistema.
2.3.2. Diseo de un Sistema de Registro Mdico Electrnico

2.3.2.1. Requerimientos
Con la finalidad de elaborar una solucin para el manejo de historias clnicas adaptada a un
sistema hospitalario, se debe realizar una serie de procesos que comienzan con el anlisis de
24

________________________________________________________________________
requerimientos, en esta etapa se ponen en perspectiva las polticas, estrategias, estructura y

directrices del sistema hospitalario. Por esa razn, esta etapa resulta fundamental para lograr
que la solucin encaje dentro de las metas del sistema hospitalario.
De esa forma, se genera un modelo, donde se representan los procesos, tareas y protocolos
que se realizan, la informacin que fluye y las reglas y normativas que rigen sobre estos
procedimientos. Este modelo permite un plan de sistemas de informacin, el cual contendr
todos los mdulos y estructura que deber poseer la arquitectura de la solucin. En este
sentido se deben tomar en cuenta la interaccin de los diferentes procedimientos que se llevan
a cabo normalmente, y la posible red de comunicacin a implementar, en hardware y software.
2.3.2.2. Anlisis / Diseo

En la fase de anlisis y diseo se utilizan los requerimientos anteriormente definidos y se
desarrolla el diseo arquitectnico del sistema que constituir la solucin.
Durante esta fase se estructura la secuencia de procesos y procedimientos, tomando en
cuenta los requerimientos de ejecucin e informacin para cada uno. Se conforma la estructura
del sistema de manera que pueda ser puesto a prueba en teora, para que funcione sin vacos de
informacin o procedimientos.
2.3.2.3. Desarrollo
Una vez que se ha definido la estructura y el contenido de la solucin, se procede a
seleccionar la herramienta de desarrollo, considerando las ventajas, desventajas y alcance de
las tecnologas disponibles.
25

________________________________________________________________________
2.3.2.4. Pruebas
Se realizan diversas pruebas de la solucin desarrollada, pudiendo conducir en muchos

casos a un rediseo de la misma. En este sentido, se procede a una prueba funcional, donde se
debe verificar que los diversos procedimientos contemplados en un principio, como registro de
pacientes, estadsticas diarias, entre otros se puedan hacer sin dificultades, de igual manera, se
debe verificar desde el punto de vista del sistema, donde el nivel de calidad y seguridad son
analizados, con el fin de garantizar que personas no autorizadas puedan tener acceso a la
informacin.
2.3.2.5. Produccin / Mantenimiento

Una vez que la solucin de manejo de historias clnicas pasa a formar parte de la vida diaria
de una institucin, resulta determinante para la calidad del servicio prestado, por esa razn,
debe contemplarse el mantenimiento y la realizacin de posibles adaptaciones o ampliaciones,
que permitan un mejor desempeo del sistema hospitalario. [9]
2.3.3. Estndar HL7

Dentro de un sistema hospitalario, no necesariamente se cuenta con la misma solucin de
aplicacin para el manejo de historias clnicas en todas las instituciones, sin embargo, los
doctores necesitan enviar y recibir informacin sobre pacientes. Resulta extremadamente
complicado el intercambio de informacin, de esa forma, surgi la necesidad de estandarizar a
travs de un formato de datos universal, la informacin de los pacientes.
En este sentido, HL7 (Health Level Seven, en ingls) es un estndar para el formato de
datos e intercambio de informacin entre diferentes sistemas de salud y su referencia al nivel
siete es debido a la dedicacin que posee a la capa de aplicacin del modelo OSI. Este
estndar, fue acreditado por la ANSI (American National Standard Institute) en su versin 2.4.
26

________________________________________________________________________
HL7 es desarrollado por una organizacin sin fines de lucro interesada en estndares para
minimizan las incompatibilidades entre sistemas de informacin en salud, permitiendo la
interaccin y el intercambio productivo de datos entre aplicaciones heterogneas,
independientemente de su plataforma tecnolgica o de su lenguaje de desarrollo. [10]
Cabe destacar que la solucin para el manejo de historias clnicas en el Sistema
Hospitalario Venezolano, no necesariamente debe tratarse de una implementacin nica
(software de gestin hospitalaria), sino de soluciones diversas a dar respuestas a distintas
particularidades; el estndar HL7 resultara una solucin eficaz para la interconexin de los
mismos.
2.4. REQUERIMIENTOS
LINEAMIENTOS
DE
DESARROLLO
IMPLEMENTACIN DE SOFTWARE MEDICO EN VENEZUELA
2.4.1. Plan Nacional de Migracin a Software Libre

En el software libre convergen algunos de los principios sustantivos de la Constitucin de
la Repblica Bolivariana de Venezuela como son: el acceso al conocimiento, equidad,
solidaridad, justicia, los sistemas de produccin cooperativistas, entre otros. Todo esto porque
los lineamientos gubernamentales consideran que el software libre permite que el
conocimiento producido pueda ser compartido y que sea disponible para que otros lo utilicen y
mejoren, incrementando las potencias transformadoras del conocimiento.
En este sentido, se ha emprendido el Plan Nacional de Migracin a Software Libre por
parte del Estado, el cual deber impulsar y fortalecer la Industria Nacional de Software, as
como garantizar la viabilidad del proceso de migracin a Software Libre y su sostenibilidad,
de manera conjunta con las universidades y el sector productivo. [11] [12]
27

________________________________________________________________________
De esa manera, se apoya la implementacin de software basado en estndares abiertos para

todas las instituciones del estado, siempre y cuando cumpla con los criterios y estndares de
seguridad y calidad establecidos por el Ministerio de Ciencia y Tecnologa y con los principios
de integracin, flexibilidad, auditabilidad e interoperabilidad.
De implementarse un sistema de manejo de historias clnicas para el Sistema Pblico
Nacional de Salud, debe cumplir los lineamientos antes mencionados.
2.5. HERRAMIENTAS DISPONIBLES PARA DESARROLLO DE REGISTROS

MDICOS ELECTRNICOS ADAPTADOS A SISTEMAS DE INFORMACIN
2.5.1. Desarrollo de Aplicaciones Web

En la actualidad, existe una marcada tendencia de implementar y desarrollar aplicaciones
en entorno Web, debido a su alcance, modularidad, universalidad, multiplataforma, entre otras
grandes ventajas, representando una opcin vlida para los sistemas de manejos de historias
clnicas, para ello deben considerarse las principales herramientas de desarrollo e
implementacin disponibles.
2.5.1.1. PHP
PHP resulta del acrnimo de Hypertext Preprocessor, en ingls y es un lenguaje de cdigo
abierto interpretado, de alto nivel, embebido en pginas HTML y ejecutado en el servidor; este
lenguaje de programacin es empleado normalmente para la creacin de pginas web
dinmicas.
PHP puede ser utilizado en cualquiera de los principales sistemas operativos del mercado,
incluyendo Linux, muchas variantes Unix (HP-UX, Solaris y OpenBSD), Microsoft Windows,
Mac OS X y RISC OS. PHP soporta la mayora de servidores web, entre los que se
28

________________________________________________________________________
encuentran: Apache, Microsoft Internet Information Server, Personal Web Server, Netscape e
iPlanet y Oreilly Website Pro server.
En cuanto a base de datos, se puede emplear en una gran cantidad de tipos, entre los que se
destacan: MySQL, Oracle, PostgreSQL, Adabas D, dBase, Hyperwave, InterBase, FrontBase,
Ovrimos.
Adicionalmente, este lenguaje tiene la posibilidad de implementar programacin orientada
a objetos; no slo se limita a resultados en HTML, sino que incluye: creacin de imgenes,
archivos PDF, pelculas Flash, XHTM y archivos XML.
Con PHP se pueden crear sockets y utilizar objetos Java de forma transparente. PHP es
multiplataforma,
con innumerables extensiones, que otorgan un amplio rango de
funcionalidades y flexibilidad al usuario. [13]
2.5.1.2. JSP: Java Server Pages

Java Server Pages es una tecnologa Java que permite generar contenido dinmico para
web, en forma de documentos HTML o XML; fue desarrollada por la compaa Sun
Microsystems y emplea el lenguaje de programacin Java mediante scripts. Resulta
independiente de alguna plataforma en especfico.
Es posible utilizar algunas acciones JSP predefinidas mediante etiquetas, enriquecidas
mediante la utilizacin de libreras de etiquetas, externas e incluso personalizadas.
Java Server Pages es una extensin de la tecnologa de servlets, que a su vez son mdulos o
programas que se ejecutan en el servidor, diseados para ofrecer contenido dinmico y que no
poseen especificacin de para alguna plataforma en particular.
29

________________________________________________________________________
Cabe destacar, que JSP emplea etiquetas para encapsular la lgica que genera el contenido
para la pgina, a travs de las etiquetas, la pgina tiene acceso a la aplicacin lgica que puede
residir en componentes tipo JavaBeans, todo esto, con el objetivo de mantener el formato o
diseo separado de la lgica.
De esta manera, se ofrece una alternativa atractiva para el desarrollo debido a su
independencia de plataformas, mejoras en ejecucin, facilidades de administracin, entre
otros. [14]
2.5.1.3. ASP: Active Server Pages

Microsoft Active Server Pages es el ambiente de ejecucin del Microsoft Internet
Information Server (IIS) que habilita la ejecucin de los scripts Activex, todo esto con la
finalidad de generar aplicaciones web dinmicas y poderosas. Posee gran capacidad de
extensin, para generar nuevos componentes, pudiendo emplear para ello, Microsoft Visual
Basic, Visual C++, Java, entre otros.
Por otro lado, ASP soportar cualquier browser o explorador, esto debido a que el producto
final es tipo Html. De maner similar, en cuanto a bases de datos, ASP puede ser integrado con
cualquier base de datos tipo ODBC incluyendo Microsoft SQL Server, Oracle, Sybase,
Informix, entre otras.
Sin embargo, resulta relevante mencionar que slo es soportado por algunas versiones de
Windows NT y Microsoft Windows 95. [15]
30

________________________________________________________________________
2.5.1.4. Ruby on Rails
Rails es un completo entorno de cdigo abierto escrito en el lenguaje de programacin

Ruby, destinado a desarrollar aplicaciones web, siguiendo el paradigma de la arquitectura
Modelo Vista Controlador (MVC).
Rails se puede implementar con diversos servidores web, pero se recomienda el uso
Apache. En cuanto a la base de datos, se puede implementar MySQL, PostgreSQL, SQLite,
Oracle, SQL Server, entre otros. Adicionalmente, Ruby on Rails puede funcionar sobre
cualquier sistema operativo.Su arquitectura se encuentra distribuida entre:
Modelo: contiene las clases que modelan los datos almacenados en la base de datos de la
aplicacin.
Vista: es la lgica de visualizacin de la aplicacin.
Controlador: maneja la peticin web recibida desde el usuario e invoca a la lgica de la
aplicacin.
Helpers: se emplean para asistir a las clases de modelos, vistas y controladores.
Adicionalmente, Rails ofrece Ajax on Rails, que es una tcnica que permite usar Javascript
y XML para procesar peticiones de un navegador web a un servidor web como procesamiento
en segundo plano sin cargar otras pginas web adicionales. [16]
2.5.2. Desarrollo de Base de Datos

2.5.2.1. MySQL
Mysql en los ltimos aos ha tenido un crecimiento vertiginoso, es la base de datos de
cdigo abierto ms popular, convirtindola en la actualidad en una solucin viable para la
administracin de datos.
31

________________________________________________________________________
Mysql constituye un sistema de administracin de bases de datos relacional (RDBMS), se

trata de un programa capaz de almacenar una enorme cantidad de datos de gran variedad y de
distribuirlos de acuerdo con los requerimientos.
Mysql ofrece una solucin con mltiples ventajas: en cuanto a costos, es gratuito; en lo
asistencial, facilita el mantenimiento, multiplataforma, ya que puede ser ejecutada en una gran
variedad de sistemas operativos. [17]
2.5.2.2. Oracle
Oracle es un sistema de administracin de base de datos relacional poderoso, fabricado por
Oracle corporation, resulta ser bsicamente una herramienta cliente/servidor para la gestin de
Bases de Datos, pero de elevado precio. [18]
Posee muchas caractersticas que garantizan la seguridad e integridad de los datos; las
transacciones se ejecuten de forma correcta, sin causar inconsistencias; ayuda a administrar y
almacenar grandes volmenes de datos; estabilidad, escalabilidad y es multiplataforma. [19]
2.5.2.3. PostgreSQL
PostgreSQL un sistema de administracin de base de datos relacional de cdigo abierto,
desarrollado por la Universidad de California.
En general, este sistema de administracin de base de datos puede ser empleado en
Microsoft Windows NT y Unix, presentndose de esa manera como una solucin
multiplataforma, con las funcionalidades de sistemas privados. [20]
32

________________________________________________________________________
2.6. REVISIN DE SISTEMAS DE REGISTROS MDICOS ELECTRNICOS

DISPONIBLES
Existen diversas soluciones comerciales que ofrecen solucin para el manejo de historias
clnicas, con diferentes enfoques, niveles de atencin previstos, mdulos desarrollados, y
diversas tecnologas de desarrollo. Los sistemas de registros considerados a continuacin
cumplen con los lineamientos gubernamentales mencionados:
2.6.1. OpenHis
OpenHIS es una plataforma de informacin hospitalaria abierta, desarrollada de acuerdo a
la realidad asistencial y gerencial hospitalaria de la regin de Buenos Aires y pretende ser la
base para el desarrollo futuro de sistemas de informacin hospitalarios para Latinoamrica. El
lenguaje de programacin implementado es PHP y la base de datos recomendada es MySQL.
OpenHIS es un desarrollo creado totalmente desde cero, con nuevo diseo, sus siglas
significan Entorno Abierto de Informacin para Salud (Open Health Information System
Environment, en ingls), su interfaz de usuario se puede apreciar a continuacin:
Figura 1. OpenHIS
33

________________________________________________________________________
Posee numerosos mdulos de gestin, tales como: Identificacin, Turnos, incluyendo citas
especialistas, Bsqueda de pacientes, entre otras funcionalidades bsicas. [21]
2.6.2. Proyecto Red-HL7 Universidad Simn Bolvar

El proyecto Red-HL7 es un sistema de informacin hospitalario abierto, desarrollado por
estudiantes de Ingeniera en Computacin como requisito aprobatorio para la cadena de Redes
de Computadoras en la Universidad Simn Bolvar; su interfaz se encuentra desarrollada con
JSP, se basa en la implementacin del protocolo HL7, junto con la funcionalidad y mdulos
bsicos que requiere una historia clnica. La base de datos recomendada fue MySQL y el
servidor Apache. [22]
A continuacin se presenta la interfaz de usuario del sistema:
Figura 2. Red-HL7
34

________________________________________________________________________
2.6.3. Care2x
Care2x es un sistema de gestin hospitalaria, que integra datos y flujo de tareas en el
entorno del cuidado de la salud, su diseo est compuesto por cuatro componentes principales:
HIS - Sistema de Informacin Hospitalaria/Servicios de la Salud, PM - Administracin del
Ejercicio Mdico, CDS - Servidor Central de Datos y HXP - Protocolo de Intercambio de
Datos de la Salud, sin embargo, en la actualidad slo se encuentra operativo el mdulo HIS Sistema de Informacin Hospitalaria/Servicios de la Salud. Desarrollado en PHP.
Care2x HIS viene con un instalador automtico, que permite al usuario configurar la base
de datos, datos de administracin, as como contraseas de acceso al sistema y puede ser
utilizado con una amplia variedad de servidores y bases de datos. Adicionalmente, permite
anexar la nomenclatura internacional de enfermedades CIE10.
Care2x soluciona los problemas del software mltiple, redundancia de datos e
incompatibilidad, ya que los mismos pueden ser compartidos a lo largo de toda la red
mediante contraseas y privilegios otorgados a los usuarios.
De igual manera, soluciona el problema de la dependencia de plataforma y permite la
creacin de nuevos mdulos de programas, que conduzcan a la adaptacin del sistema a
determinada institucin o sistema hospitalario. [23]
35

________________________________________________________________________
Figura 3. Care2x HIS
2.7. CONCEPTOS BSICOS DE REDES DE TRANSMISIN DE DATOS PARA

SISTEMAS DE REGISTROS MDICOS ELECTRNICOS EN VENEZUELA
2.7.1. Arquitectura Cliente - Servidor

El modelo cliente/servidor, opera de la siguiente manera: el servidor espera por una
peticin de un cliente, abre una sesin, enva la informacin solicitada y al finalizar la
trasferencia la cierra, mientras que el cliente es el que realiza la peticin y recibe la
informacin solicitada.
Una de las caractersticas principales del modelo es que el servidor no se ejecuta
necesariamente sobre una sola mquina, ni es necesariamente un slo programa. Puede tratarse
de diferentes programas ejecutados por diferentes computadoras, aumentando as el grado de
distribucin del sistema.
36

________________________________________________________________________
Esta arquitectura, permite el control de accesos, recursos y la integridad de los datos por
parte del servidor, de forma que un programa cliente defectuoso o no autorizado no pueda
daar el sistema, igualmente, permite la escalabilidad, ya que se puede aumentar la capacidad
de clientes y servidores por separado.
Algunas redes pueden estar constituidas tpicamente por un cliente, servidor de procesos y
servidor de base de datos. La ventaja de una arquitectura de tres elementos, es que separa
hacia fuera el proceso, de manera que sea ms escalable.
El modelo Cliente/Servidor puede incluir mltiples plataformas, bases de datos, redes y
sistemas operativos.
2.7.1.1. Sockets
Normalmente un servidor es requerido por un nmero determinado de clientes, con la
finalidad de atenderlos, se establece una conexin entre el servidor y cada uno; de manera que
se pueden realizar las siguientes operaciones bsicas:
Conectar con una maquina remota.
Enviar data.
Recibir data.
Cerrar conexin.
Vinculo a puerto.
Espera de datos entrantes.
Aceptar conexin con maquina remota por medio de puerto vinculado.
Se presenta un caso de conexin realizado en PHP, donde se muestra un servidor simple
que repite de vuelta su entrada (ver Anexo 10.11.).
37

________________________________________________________________________
2.7.2. Red de datos CANTV

CANTV, empresa lder en telefona mvil y fija a nivel nacional, provee soluciones de
comunicaciones, con tecnologa y responsabilidad social, en este sentido, ofrece cobertura en
la mayor parte del territorio nacional y por tratarse de una empresa del estado, proporciona en
este caso, una pasarela de datos para la solucin de manejo de historias clnicas adaptado al
sistema hospitalario. [24]
2.7.2.1. Tipos de Conexin y Acceso

Los servicios de conexin y transmisin de datos que ofrece actualmente la compaa
vienen dados por su tipo de acceso, ya que puede tratarse de una conexin por pares de cobre
o por una conexin inalmbrica. En el primer caso, la solucin principal ofrecida es un modem
que funciona sobre la tecnologa ADSL, Asymmetric Digital Subscriber Loop en ingls, la
cual brinda una conexin digital con velocidades de subida y de bajada diferentes.
Esta tecnologa est pensada tpicamente para servicios de acceso a Internet, en los que, por
lo general, es mucha ms la informacin que debe viajar desde Internet hacia el usuario, que
desde el usuario hacia Internet. Todo esto sin excluir el servicio telefnico de voz, tal como se
aprecia en la siguiente figura:
Central
Telefnica
Abonado
Rede
Cable Multipar
Switch
Telefnica
DSLAM
Internet
Filtro
ADSL
modem
Figura 4. Transmisin ADSL

38

________________________________________________________________________
Los servicios ADSL pueden ser brindados a diferentes velocidades de subida y bajada,
en CANTV, empleando el Plan Productivo, alcanzan 512kbps y 1536 kbps respectivamente.
ADSL permite que sobre un mismo par telefnico puedan coexistir un servicio telefnico
analgico y un servicio de datos. Para lograr esto, se utiliza modulacin en frecuencia y
separadores o filtros. Estos filtros separan el servicio telefnico del servicio de datos, ver
figura 5. El servicio telefnico es conectado a un telfono analgico y el servicio de datos a un
modem, en este sentido la solucin comercial de CANTV, posee dos conectores: uno de red
RJ45 y puerto USB.
Figura 5. Distribucin de Servicios en ADSL
Para poder emplear el servicio de ADSL de CANTV en la solucin para el manejo de

historias clnicas, debe cumplirse que el terminal de conexin pertenezca a una central con
disponibilidad de aba y que en ese caso, se encuentre dentro de un radio de 5 Km de la Central
Telefnica.
CANTV tambin ofrece solucin inalmbrica, destacndose la implementacin de un
modem con conexin USB para aplicaciones celulares, la tecnologa empleada es EVDO, que
es un estndar de transferencia de datos, perteneciente a la familia CDMA2000 y que ha sido
adoptado por muchos proveedores a nivel mundial. [25]
39

________________________________________________________________________
El modelo de EVDO se basa en el modelo de internet TCP/IP en sus capas fsica y de

enlace, posee siete capas y cumplen las siguientes funciones:
Capa de Aplicacin: provee la aplicacin de sealizacin estndar para el transporte de
mensajes del protocolo de interfaz de rea.
Capa de Caudales: proporciona la multiplexin de caudales distintos de aplicacin.
Capa de Sesin: proporciona el manejo de configuracin de protocolos y sesin.
Capa de Conexin: establecimiento y mantenimiento de la conexin.
Capa de Seguridad: servicios de autenticacin y encriptacin.
Capa de Acceso al medio: define procedimientos para recibir y transmitir datos sobre la
capa fsica.
Capa Fsica: estructura de canales, frecuencia, potencia de salida, modulacin y
codificacin de seal.
La solucin comercial de CANTV ofrece conexiones desde 300 kbps hasta 600 kbps,
llegando a picos de 2Mbps.
2.8. SISTEMA DE ENERGA DE RESPALDO

Los sistemas de alimentacin de respaldo son implementados para proteger y suministrar la
energa suficiente a equipos en caso de perturbaciones o ausencia de su sistema de
alimentacin habitual.
2.8.1. Sistemas de alimentacin de respaldo para cargas crticas

Las perturbaciones de la corriente alterna (AC) o red comercial pueden ser de amplitud,
frecuencia o forma de onda, entre las que se destacan: [26]
Picos de tensin: se refiere a las sobretensiones transitorias causadas por operaciones de
conmutacin y descargas electroestticas.
40

________________________________________________________________________
Ruido: Interferencia electromagntica, electroesttica y se interferencia de seales de radio,

causado por motores y tormentas elctricas.
Sobretensin Momentnea: incremento superior al 10% de la tensin RMS, con duracin
de ciclo a unos cuantos segundos.
Sobretensin Permanente: incremento superior al 10% de la tensin RMS, con duracin
mayor de unos cuantos segundos.
Desvanecimiento (Black Out): prdida total de tensin durante un periodo de tiempo
tpicamente mayor a ciclo.
Por otro lado, los equipos electrnicos alimentados son modelados como cargas dentro del
sistema de energa, clasificndose en dos categoras:
Carga no critica: posee una ventana de voltaje de entrada amplia, es decir que sus
especificaciones permiten valores de entrada sin grandes restricciones, por encima y por
debajo de su voltaje nominal de ejecucin.
Carga crtica: si resulta sensible a la calidad de la alimentacin que le llega, rangos de
entrada y perturbaciones que pueden daar o perjudicar, la aplicacin de la que se encargan.
Igualmente, durante el establecimiento de un sistema de respaldo se debe tomar en
consideracin que se puede tratar de una carga de tipo AC o una carga de tipo DC.
2.8.2. Confiabilidad
El sistema de alimentacin debe proveer a su carga (equipo) confiabilidad, de manera que
le garantice calidad y disponibilidad de energa para operar una aplicacin dada. Ante una
perturbacin, el sistema de respaldo actuar reemplazando la alimentacin y suministrando a
la carga la energa necesaria para su funcionamiento. Por lo tanto, resulta sumamente
importante realizar el estudio y dimensionamiento de estos sistemas de acuerdo con la carga a
proteger.
41

________________________________________________________________________
2.8.3. Configuraciones Tpicas

Las configuraciones tpicas para cargas crticas dentro de los sistemas de respaldo, son los
siguientes:
Sistema en paralelo: esta configuracin se encuentra constituida de manera tal que puede
operar en dos modos. En el primero de ellos, la red entrega voltaje AC y se convierte en DC a
travs de un dispositivo inversor AC/DC, para poder alimentar tanto a la carga como a la
batera. Por lo general, la batera debe ser del mismo voltaje nominal (VNOM) de la carga.
I REC
VFLOTACION
AC
ICARGA
VMAX
V
I BAT
Carga DC
VMIN
Convertidores
VBAT
AC - DC
Bateras
Figura 6. Sistema paralelo en operacin normal
El voltaje que debe salir del rectificador se llama voltaje de flotacin (VFOLT) y debe ser
ajustado para encontrarse en la ventana de entrada de la carga (V) y dentro del rango para
mantener la batera cargada y evitar con ello una auto descarga; la corriente del rectificador
debe ser lo suficientemente amplia para atender los requerimientos tanto de las bateras como
de las cargas.

En ausencia o desvanecimiento de la alimentacin, el sistema opera en su segundo modo:
ausencia de AC. En el cual comienza un flujo natural de energa desde la batera hacia las
cargas, la seccin que tiene que ver con la red AC y el inversor AC/DC queda desconectada
del sistema, de forma tal que la batera provee la energa suficiente a la carga, para que no note
la ausencia de la misma.
42

________________________________________________________________________
ICARGA
VFLOTACION
VMAX
V
I BAT
Carga DC
VMIN
Convertidores
AC
VBAT
AC - DC
Bateras
Figura 7. Sistema paralelo durante falla de red elctrica de alimentacin
Si se requiere proporcionar al sistema de mayor capacidad de energa almacenada, se puede

aplicar redundancia en las bateras, tal como se muestra en la figura 8, dicho procedimiento se
lleva a cabo al conectar en paralelo dispositivos con la misma funcin de manera adicional a la
cantidad necesitada.
La redundancia se lleva a cabo considerando el criterio N + M, en donde N es el nmero de
elementos necesarios y M el nmero de elementos redundantes, siendo comn en la prctica el
empleo de N+1.
Bateras
AC
Carga DC
Convertidores
AC - DC
Figura 8. Redundancia de Bateras
43

________________________________________________________________________
La versatilidad de la configuracin en paralelo permite que un sistema de energa de

respaldo pueda ser diseado con el objetivo de proteger no una, sino varias cargas,
considerando que la configuracin deber suministrar energa, en sus diferentes modos, acorde
con los requerimientos de corriente de las mismas y presentando la siguiente configuracin:
Carga DC
AC
Convertidores
Carga DC
AC - DC
Bateras
Carga DC
Figura 9. Sistema de respaldo para varias cargas
Otra aplicacin de la configuracin en paralelo es la dirigida a proteger cargas AC,

colocando para ello un inversor DC AC justo antes de la carga:
Carga AC
AC
Convertidores
Convertidores
AC - DC
DC- AC
Bateras
Figura 10. Sistema de Respaldo en paralelo para cargas AC
Sistema Conmutado, esta configuracin es alternativa a la paralela, para su implementacin

se requiere de un sistema de control que monitoree la entrada y de acuerdo al valor de la
misma, seleccione y active un modo de operacin. El primero de ellos ocurre si la red se
encuentra conectada al sistema, se estructura mediante dos lneas de alimentacin, una de ellas
44

________________________________________________________________________
alimenta mediante un inversor AC DC a la carga, manteniendo activa su operacin, la

segunda lnea, alimenta a las bateras a travs de otro dispositivo inversor AC DC, tal como
se aprecia a continuacin:
Switch
AC
ICARGA
VMAX
V
Carga DC
VMIN
Convertidores
AC - DC
Sistema de
Control
I BAT
Convertidores
AC - DC
VBAT
Bateras
Figura 11. Sistema Conmutado en modo normal
En su segundo modo, en ausencia de la red AC, se conectan las bateras con la carga,
inicindose el ciclo natural de descarga, descrito con anterioridad, quedando el resto del
sistema desconectado, tal cual como se aprecia en la siguiente figura:
45

________________________________________________________________________
ICARGA
Switch
AC
VMAX
Carga DC
VMIN
Convertidores
AC - DC
Sistema de
Control
I BAT
Convertidores
AC - DC
VBAT
Bateras
Figura 12. Sistema Conmutado en modo de descarga
De forma anloga al sistema en paralelo, esta configuracin tambin puede estar dirigida a
proteger cargas AC, colocando para ello un inversor DC AC justo despus de la batera y
retirando el inversor AC DC en la lnea de conexin de la red y la carga, tal como se muestra
a continuacin:
Switch
Carga AC
AC
Sistema de
Control
Convertidores
Convertidores
AC - DC
DC - AC
Bateras
Figura 13. Sistema de Respaldo Conmutado para cargas AC

46

________________________________________________________________________
2.8.4. Bateras estacionarias.

2.8.4.1. Operacin y caractersticas
Las bateras son dispositivos acumuladores de energa, constituidos por celdas
electroqumicas, como unidad bsica. Operan esencialmente debido a la reaccin generada
entre electrodos, positivo y negativo, sumergidos en una solucin electroltica, de manera que
se genera una diferencia de potencial entre los electrodos, tal como se aprecia en la figura 14:
Placas
Electrolito
Figura 14. Constitucin bsica de una batera
Cada celda a su vez se encuentra compuesta por conjunto de placas positivas y negativas
separadas por aislantes, participando de esa manera en la reaccin electroqumica de carga y
descarga, sus dimensiones son proporcionales a la capacidad de la batera para suministrar
energa. Resulta importante destacar que el conjunto de placas se conectan con los terminales
nicos de la batera, de manera que slo existan dos conexiones externas: borne positivo y
borne negativo.
Las bateras pueden estar constituidas por celdas electroqumicas de diversos tipos, los
cuales determinarn su modo de operacin:
Celdas Electroqumicas Primarias: diseadas para conversin de energa en una sola
direccin, energa qumica en elctrica, es decir, slo permiten la descarga.
Celdas Electroqumicas Secundarias: diseadas para una doble conversin de energa,
llevada a cabo mediante el uso de un proceso electro-qumico reversible. La primera
47

________________________________________________________________________
conversin es la transformacin de energa elctrica en energa qumica, la cual toma lugar

durante el proceso de carga. La segunda conversin es la transformacin de energa
qumica en elctrica, la cual ocurre cuando la batera se descarga. De esa manera, la energa
puede entrar y salir, permitiendo una vida til de un determinado nmero de ciclos.
Durante la vida til de una batera con celdas electroqumicas secundarias, la misma
experimenta numerosos procesos de descarga y carga, denominados ciclos, cada ciclo puede
descargar la batera en un porcentaje diferente de su capacidad de acumulacin de energa,
constituyendo as la profundidad del ciclado; ambos parmetros resultan esenciales, ya que
proporcionan informacin sobre el Estado de carga (EDC) o State of Charge (SOC), en ingles,
con lo cual se puede indicar el porcentaje de energa que ha sido descargado para luego ser
repuesto, tal como se muestra en la siguiente figura:
SOC
100%
Ciclo Suave
Ciclo Profundo
Ciclo Completo
Tiempo
Figura 15. Profundidad de Ciclado
A medida que el ciclo sea ms profundo, es decir que se haya descargado ms la batera,
mayor ser el esfuerzo de la misma durante el proceso de carga para reponer la energa
extrada, desgastando a la misma.
Las bateras pueden ser clasificadas de acuerdo con su aplicacin:
Bateras de traccin: diseadas para propulsar motores elctricos, empleadas en vehculos
industriales y submarinos.
48

________________________________________________________________________
Bateras estacionarias: diseadas para fuentes de alimentacin de emergencia y fuentes de

alimentacin ininterrumpida para usos de informtica.
Bateras de arranque: diseadas para encender vehculos de combustin.
En este sentido, las bateras pueden ser clasificadas de acuerdo a la constitucin de sus
celdas electroqumicas, es decir, el material de sus electrodos y sustancia electroltica,
destacndose las que se muestran a continuacin:
Plomo cido
Electrodo positivo: Dixido de Plomo

Electrodo negativo: Plomo
Electrolito: cido Sulfrico
VNOM 2 voltios /celda
Nquel Cadmio
Electrodo positivo: Hidrxido de Nquel

Electrodo negativo: Cadmio
Electrolito: Hidrxido de Potasio
VNOM 1,2 voltios /celda
Electrodo positivo: Hidrxido de Nquel

Electrodo negativo: Aleacin de Metal-Hidruro
Electrolito: Hidrxido de Potasio
BATERIAS
Nquel Metal
Hidruro
Litio Ion
Electrodo positivo, negativo y electrolito:

favorecen el transporte de iones de litio
La seleccin de la batera depender de la aplicacin que se le quiera dar a la misma.
49

________________________________________________________________________
De manera especfica, las bateras de plomo cido pueden presentarse comercialmente en

dos tipos:
Abiertas, ventiladas e inundadas: estas bateras poseen una abertura en la parte superior del
dispositivo, de manera que permite el ingreso de la sustancia electroltica junto con agua,
para que la batera pueda operar. Requiere de mantenimiento peridico con la finalidad de
medir el nivel de cido y reponer la cantidad faltante. Por lo tanto, se necesita que la
manipulacin de este tipo de bateras se haga con material de proteccin y en espacios
idneos para el manejo del cido.
Durante el proceso de carga, todas las bateras realizan un proceso denominado
gasificacin, donde la sustancia electroltica se desgasta y pierde vapor de agua, para ello,
las bateras tipo ventiladas operar con rejillas, de esa forma, no permite mucha movilidad y
requiere de espacios con ventilacin, como su nombre lo indica.
Selladas, cerradas: las bateras selladas son mucho ms compactas, para contrarrestar el
proceso de gasificacin, realizan recombinacin de gases, restituyendo un gran porcentaje
de lo gasificado, de forma interna y adems posee vlvulas de regulacin que sirven de
alivio, Valve Regulated Lead Acid (VRLA), en ingles.
Las bateras selladas demandan menos mantenimiento y permiten condiciones ms flexibles
de entorno, adems de mayor movilidad, todo esto hace que sean una de las ms
implementadas en energa de respaldo para estaciones de telefona mvil.
Considerando que las bateras de plomo-cido ofrecen un voltaje nominal por celda de 2
voltios y que los valores tpicos para las aplicaciones de respaldo de energa son: 12 voltios,
24 voltios y 48 voltios, se establece un nmero nominal de celdas, que conectadas en serie
hasta llegar a los extremos externos, pueden alcanzar los voltajes tpicos deseados, tal como se
muestra a continuacin:
50

________________________________________________________________________
Tipo de Batera
12 voltios
24 voltios
48 voltios
6 celdas
12 celdas
24 celdas
Plomo cido
2 voltios por celda
Tabla 2. Voltaje Nominal de batera de Plomo-cido
Otro factor de importancia es el comportamiento de la corriente y voltaje en la batera,

durante el periodo de carga, en una configuracin en paralelo, tanto la carga, como la batera
deben recibir un voltaje (VFLOT), que por un lado, suministre energa suficiente a la carga y por
el otro, evite la auto descarga en la batera, con la finalidad de mantenerla preparada para una
situacin de ausencia AC, tal como se puede apreciar en el modo normal de la figura 16.
De esa forma, se debe cumplir que el voltaje de flotacin sea mayor que el voltaje de auto
descarga mencionado por el fabricante para la batera y menor al voltaje mximo de entrada de
la carga, tal como se aprecia en la siguiente expresin:
/ , donde es el nmero de celdas
Una vez que la red es desconectada, comienza la descarga y ahora es la batera la que
suministrar el voltaje y corriente a la carga, comenzando con un voltaje , sin
embargo, a medida que entrega energa, se descarga y si este proceso no se detiene, la batera
alcanzar el valor de , momento en el que ya no puede seguir entregando energa, tal
como se muestra en el modo de ausencia AC de la siguiente figura:
51

________________________________________________________________________
V
VFLOT
VINICIAL
VFINAL
I
ICARGA
Modo
Modo
Normal
Ausencia AC
TFINAL
TFINAL
Figura 16. Batera durante operacin
En este sentido, para dimensionar un sistema de respaldo, se debe determinar el valor del
voltaje final de la batera para que sea mayor al VMIN de alimentacin de la carga, ya que no
tiene sentido seguir descargndola mientras se alimenta a la carga con un voltaje que no
permite su funcionamiento. Se define un voltaje final de descarga o , con este parmetro se
representa el valor mnimo que puede alcanzar la batera durante la descarga para mantener
operativa a la carga, cabe destacar que el voltaje final se expresa por celda y por esa razn se
debe tomar en cuenta el nmero de celdas en total de la batera , finalmente, se puede
determinar a partir de la siguiente expresin:
/ =
Con el objetivo de prolongar el tiempo de descarga y con ello proporcionar a la carga
mayor tiempo de autonoma ( ), es decir, tiempo de energa en caso de ausencia AC, se
debe ajustar el consumo de la carga, ya que a menor corriente requerida mayor es el tiempo
que la batera puede proporcionar energa, tal como se puede apreciar en la siguiente figura:
52

________________________________________________________________________
V
V3 fd
V2 fd
V1 fd
I
I1 CARGA
I2 CARGA
I3 CARGA
T1 AUT T2 AUT
T2 AUT
Figura 17. Requerimiento Energtico vs. Tiempo de Autonoma
Por esa razn, resulta tan importante en el momento de dimensionar un sistema de respaldo
de energa, lograr minimizar el consumo de corriente.
2.8.4.2. Capacidad
Para un sistema de energa de respaldo resulta de suma importancia la capacidad la batera,
ya que indica la cantidad de energa que la misma puede ofrecer antes de llegar a su voltaje
final de descarga. La unidad de capacidad empleada para las bateras es: Ampere por hora
(. ) y de manera especfica, representa los amperes entregados en un determinado periodo
de tiempo. Ver siguiente figura:
53

________________________________________________________________________
V
VINICIAL
VFINAL
I
IREQUERIDA
L
Tiempo
Figura 18. Capacidad de batera
En vista de la gran variedad de bateras existentes en el mercado, se establece un estndar,

punto de comparacin que indica la forma y condiciones tpicas para el clculo de la
capacidad, de manera particular, las bateras de plomo-cido emplean los parmetros IEEE:
=
Condiciones:
: 8 horas
VFINAL /CELDA : 1,75 Voltios
Temperatura: 25 C
En concentracin de electrolito: 1,215
Durante el proceso de dimensionamiento, se debe realizar la seleccin de las bateras

tomando en cuenta los requerimientos del sistema, para ello se estima la capacidad requerida y
con ella se ubica el modelo de batera idnea.
Con la finalidad de que la capacidad calculada bajo los parmetros IEEE, pueda garantizar
que la batera an bajo condiciones no ideales de temperatura, de diseo de fbrica o cuando
sufra envejecimiento siga prestando servicio, se incorporan diversos factores en el clculo, de
manera que acten como factores de correccin y permitan seleccionar la batera realmente
adecuada:
54

________________________________________________________________________
Factor de Diseo : considerado debido a las condiciones de fabricacin, su valor se
estima entre 1,10 a 1,15

Factor de Temperatura : la temperatura resulta ser una condicin importante con respecto
a la capacidad, esto debido a que temperaturas menores a los 25 C no favorecen a las

reacciones dentro de las bateras, reduciendo as su capacidad, lo que se representa con un
factor menor que uno; mientras que, temperaturas superiores a 25 C si favorecen a la
capacidad, de esa manera, el factor que se introduce es superior a uno.
Factor de Envejecimiento: con el pasar del tiempo de su vida til, la batera comienza a
desgastarse y con esto a proporcionar menor energa de la estimada en un principio, lo que

se puede ver reflejado en la siguiente figura:
Capacidad
100%
80%
Muerte Sbita
Figura 19. Envejecimiento de Batera de Plomo - cido
Cuando la batera se acerca al 80% del voltaje nominal se acerca a la muerte sbita, donde
deja de funcionar de manera repentina, es por eso que se introduce un factor mayor que uno,
para sobredimensionar la batera y poder gozar de energa por ms tiempo, es decir que an
llegando a su 80% de capacidad, todava se encuentre entregando la energa suficiente para la
carga, de esa manera se tiene:
0,8 = 1
Se obtiene = 1,25
Finalmente, se emplea la capacidad segn el estndar IEEE para bateras de Plomo cido
tomando en cuenta las correcciones, tal como se aprecia a continuacin:
55

________________________________________________________________________
=
2.8.4.3. Seleccin y dimensionamiento de bateras.

Para el dimensionamiento de las bateras para un sistema de energa de respaldo, se debe
llevar a cabo el proceso que se describe a continuacin:
Se establecen los requerimientos de la carga.
Se selecciona la tecnologa; se realiza un estudio de las diversas tecnologas de bateras
disponibles y se selecciona la clase ms adecuada a las necesidades y prioridades segn

criterios de costo, peso, efectividad, rendimiento, entre otros. De manera que se pueda
contar con un grupo de modelos comerciales para la posterior seleccin.
Se determina el nmero de celdas a implementar y voltaje final de descarga segn
requerimientos de la carga.
Se determina la capacidad requerida para mantener a la carga operativa, para ello se recurre
a tablas y dems hojas tcnicas de modelos de bateras considerados para la seleccin.

Igualmente, se toma en cuenta los diferentes factores de correccin que resulten pertinentes.
Se selecciona la batera a ser implementada en el sistema de respaldo de acuerdo con los
parmetros anteriormente determinados.
2.8.5. Rectificadores-cargadores de bateras

2.8.5.1. Caractersticas y dimensionamiento
Este dispositivo se encarga de suministrar energa transformada de AC a DC al sistema
durante la operacin del modo normal, es decir cuando la red se encuentra conectada. Su
dimensionamiento viene dado por dos parmetros: el primero de ellos es el voltaje, indicando
con esto el voltaje de entrada (voltaje de la red) y el de salida, que se va a utilizar para las
bateras y la carga, el segundo parmetro importante para el dimensionamiento del rectificador
56

________________________________________________________________________
es la corriente, ya que debe ser lo suficiente para poder alimentar a la batera y a la carga en
sus requerimientos, de esa forma:
= +
La corriente de la batera se calcula mediante la siguiente relacin:
=

@ 80%
Donde es el factor de eficiencia de recarga y @ 80% es el periodo de tiempo de

recarga en el que la batera alcanza el 80% de su capacidad.
2.8.5.2. Configuraciones redundantes

La redundancia se emplea cuando la carga resulta ser muy crtica y se necesita garantizar
que aunque falle el rectificador, el sistema pueda seguir operando. Se conectan en paralelo los
rectificadores y si todos funcionan, la etapa de rectificacin podr entregar mayor corriente
(Amperios) al resto del sistema; si falla uno de ellos, los dems siguen en operacin sin afectar
de manera brusca la operacin de la carga, permitiendo que el personal de mantenimiento
cambie el rectificador defectuoso.
Carga DC
AC
VFLOTACION
Bateras
Convertidores
AC - DC
Figura 20. Redundancia Rectificadores
57

________________________________________________________________________
El criterio de redundancia empleado es el N+M, pueden fallar M rectificadores sin que el

sistema deje de funcionar. A continuacin se determina la cantidad necesaria de rectificadores
(N),
considerando
que
ya
se
seleccion
el
rectificador
implementar
( ):
=
2.8.6. Sistemas de Proteccin

2.8.6.1. Breakers
Este dispositivo de proteccin se emplea con la finalidad de evitar que la corriente que
circula por la lnea, en donde se conecta, exceda un valor mximo ( ) estimado
durante el diseo y dimensionamiento del sistema.
El criterio de diseo ms empleado en la actualidad por las empresas del rea consultadas,
es el siguiente:
= 1,25
Cuando el dispositivo de proteccin detecta que la corriente alcanz el valor
se desconecta automticamente de la lnea, protegiendo as los equipos y por supuesto la carga
de la sobre corriente circulante.
VMAX
V
VFLOTACION
AC
Carga DC
VMIN
Convertidores
VBAT
AC - DC
Bateras
Figura 21. Sistema de respaldo con Breakers

58

________________________________________________________________________
2.8.6.2. Low Voltage Disconnect LVD
Este dispositivo de proteccin se emplea en el sistema de respaldo con la finalidad de evitar

el proceso de sobre descarga de la batera; esta situacin se puede presentar una vez que la
batera se encuentra descargada y no puede mantener la carga operativa, pero an sigue
suministrando energa.
El LVD debe conectarse a la entrada de las bateras o a la entrada de la carga, ya que esta
ubicacin le permite poder monitorear el voltaje entregado por la batera a la carga durante
situacin de descarga y con ello verificar si se encuentra dentro de la ventana de voltaje de
entrada de la misma; cuando se detecta que el voltaje se encuentra por debajo del voltaje
mnimo requerido por la carga, la carga no puede prestar servicio, as que se desconectan
ambos dispositivos.
VMAX
VFLOTACION
AC
Convertidores
LVD
Carga DC
VMIN
LVD
AC - DC
VBAT
Bateras
Figura 22. Sistema de respaldo con Low Voltage Disconnect
CAPITULO III: DISEO Y DESARROLLO DEL MEDICARRO
59
________________________________________________________________________

3.1. REQUERIMIENTOS
3.1.1. Hardware
Dadas las condiciones del sistema hospitalario y en particular las condiciones del hospital
de referencia, as como su secuencia de atencin, se tomaron los siguientes lineamientos para
la construccin del equipo de historias clnicas:
Desplazable (rodado): para llevarlo dentro de su rea operativa hasta el lugar donde se
encuentra el paciente.
Modular y escalable: que facilite el proceso de reproduccin en serie y futuras
ampliaciones.
Resistentes a golpes y lquido: no debe constituir un elemento delicado y vulnerable para
las situaciones de respuesta rpida de una sala de emergencia.
Diseo robusto: como resultado de las condiciones de inseguridad que presenta el pas, el
equipo de manejo de historias clnicas debe ser apto para su implementacin en el Sistema
Pblico Nacional de Salud.
3.1.2. Software
La solucin de software para el manejo de historias mdicas deba ser basada en
herramientas que permitieran posteriores ampliaciones, as como labores de mantenimiento y
administracin. Igualmente, poder permitir implementar mecanismos de seguridad para
proteger la informacin de cada paciente.
60
________________________________________________________________________
3.1.3. Operatividad
En las instituciones de salud, el personal cumple turnos de ocho horas, por lo tanto el
equipo de manejo de historias clnicas, deba poseer una modalidad de energa que le
permitiera autonoma por lo menos un turno; dicho sistema de respaldo de energa debe
encontrarse siempre preparado para garantizar operatividad en todo momento.
Como consecuencia de que el equipo necesitaba ser desplazable, la Comunicacin deba
ser inalmbrica, para el proceso de transmisin de las historias de los pacientes al servidor; se
consider inviable una conexin cableada mientras se tuviera al equipo desplazndose.
3.1.4. Anlisis de Requerimientos

Al analizar la estructura del sistema hospitalario nacional, las condiciones actuales de una
de sus instituciones ms emblemticas y las principales tecnologas y soluciones comerciales
de software para manejo de historias clnicas, surgieron diversos requerimientos, de hardware,
software y operatividad. Se consider en primer lugar, las soluciones de hardware
comercializadas en la actualidad: principalmente laptops y palms, ya que han sido empleadas
en otras aplicaciones similares y en otros pases; podran llevar a cabo la parte funcional del
sistema de manejo de historias clnicas, sin embargo, se concluy que no podran cumplir con
el resto de los requerimientos del sistema hospitalario de Venezuela.
Por consiguiente, se dio inicio al diseo de un equipo especialmente adaptado a los
requerimientos del sistema hospitalario de Venezuela, denominado Medicarro.
61
________________________________________________________________________
3.2. MEDICARRO: ESTRUCTURA GENERAL
En este sentido, el Medicarro fue conceptualizado como un equipo de manejo de historias
clnicas, adaptado a los requerimientos del sistema hospitalario, capaz ingresar datos e
informacin del paciente y transmitirlos inalmbricamente para su administracin y control, de
forma tal que cuando el paciente acuda de nuevo a la institucin o a otra diferente, pueda ser
recuperada la informacin y datos del mismo, tal como se aprecia a continuacin:
Medicarro
Medicarro
Figura 23. Funcionamiento general del Medicarro
3.2.1. Seleccin de configuracin del Sistema de Energa de Respaldo

Tomando en consideracin el anlisis de requerimientos del Medicarro, se requiri
implementar un sistema de energa de respaldo. En primer lugar, se seleccion la configuracin
a implementar, de acuerdo a criterios de eficiencia y costos.
62
________________________________________________________________________
La carga vena dada por un equipo de computacin, donde debiera operando la aplicacin de
historias clnicas, este equipo era de alimentacin AC, en este sentido, se consider tanto la
configuracin en paralelo, ver figura 10, como el sistema conmutado, ver figura 13, ambos
adaptados a cargas AC.
Sin embargo, en ambas configuraciones, el aprovechamiento de energa no es ptimo, esto
debido a que es transformada dos veces, primero de AC a DC para ser almacenada en la batera
y luego de manera inversa para poder alimentar a la carga, de esa forma, la configuracin en
paralelo emplea dos inversores, en vez de uno y la conmutada los mismos elementos pero
dispuesto de manera diferente.
Con el objetivo de proponer un sistema ms eficiente, se plante la posibilidad de modificar
las caractersticas del Medicarro de manera tal que se pudiera alimentar con DC, para este caso
se analizaron ambas configuraciones nuevamente, pero esta vez se encontr que la
configuracin en paralelo emplea un inversor, mientras que la configuracin conmutada
necesita emplear dos inversores, factor que elevaba los costos de manera significativa.
Adicionalmente, se tom en cuenta que el funcionamiento del sistema conmutado
dependera de la eficiencia del switch y su sistema de control, ya que para que la carga no sufra
durante la transicin de modos de operacin, el tiempo de respuesta debe ser corto. Esta
configuracin fuera la indicada si existiera incompatibilidad entre la ventana de voltaje de la
carga y el necesario para la batera, pero no es este el caso, debido a que se puede introducir
modificaciones en la carga para que no ocurra.
Finalmente, se concluy que la configuracin en paralelo resulta ser la ms adecuada para el
Medicarro, ver figura 6, sin la necesidad de implementar ningn dispositivo inteligente de
control.
63
________________________________________________________________________
3.2.2. Seleccin de equipos de Computacin

Tras surgir la necesidad de realizar modificaciones en el equipo de computacin para que
pudiera ser alimentado con DC, se comenzaron a analizar las posibilidades disponibles. En
primer lugar, se solicit asesora tcnica a SEEBECK, empresa lder en el rea de control e
instrumentacin a nivel nacional y tras visitas realizadas a su sede en Guarenas, se localiz un
computador de tipo industrial cuya entrada es de 24 V DC.
El equipo LinCon-8000, posee una arquitectura embebida, apto para movilidad y
funcionamiento en condiciones adversas, todo esto con dimensiones fsicas reducidas: 11
11 7,5 , su sistema operativo es Linux, incluye conexiones usb, ps/2, red, as como
memoria de 64 MB y tarjeta flash de 32MB, alcanzando los requerimientos de hardware y de
software inicialmente planteados. Ver siguiente figura:
Foto 6.
LinCon-8000
64
________________________________________________________________________
Sin embargo, la distribucin de Linux que posee es ICE WM y luego de ser manipulada se
determin que esta versin resultaba limitada, ya que no permite la instalacin de aplicaciones
en su interior; su programa explorador, Dillo, no soporta elementos de javascripts. Con la
finalidad de proponer una solucin, se convers con la empresa proveedora ICP DAS, la cual
no recomend cambiar ni la distribucin, ni el explorador.
Todo esto fue suficiente para descartar este equipo, ya que la idea del Medicarro es que
luego pueda ser ampliado y ajustable a los cambios tecnolgicos, sin encontrarse limitado.
Posteriormente, durante reuniones en la sede del CENIT se realiz una alianza estratgica
con representantes de INTEL en Venezuela y explorando entre sus diversas soluciones
comerciales, se encontr un equipo de bajo consumo, destinado a minimizar los costos
energticos, as como tamao, tal como se puede ver a continuacin:
Foto 7. Tarjeta D201GLY de INTEL
65
________________________________________________________________________
Una de las mayores ventajas de este equipo es que su procesador es Celeron, por lo tanto
puede soportar mltiples sistemas operativos, sin imponer mayores restricciones a la
aplicacin. Posee un tamao considerablemente pequeo 17 17 , que lo hace ideal
para la constitucin del Medicarro, igualmente, este equipo posee conexin de red y usb.
Una vez seleccionado el equipo de bajo consumo, se necesitaba un dispositivo que
conectara la entrada proveniente del sistema de energa (DC), con la tarjeta y que adems
fuera capaz de proveer los distintos voltajes de alimentacin a la misma, en forma de conector
ATX. Se seleccion el convertidor PicoPSU de 120W DC-DC, cuya entrada es de 12 voltios y
salida en conector ATX, tal como se aprecia a continuacin:
Foto 8. Conector de 12 V DC a Conector ATX
En cuanto a la unidad de disco, se consider conveniente implementar un adaptador a disco

flash (ver siguiente figura), debido a que resultaba mucho ms compacto en cuanto a tamao.
La tarjeta flash sugerida es de 4GB.
Foto 9. Adaptador de Disco Flash

66
________________________________________________________________________
La memoria seleccionada para el diseo del Medicarro es de 512 MB, tal como se aprecia a
continuacin:
Foto 10. Memoria RAM
En cuanto al monitor, se seleccion un modelo cuya alimentacin es DC a 12 V, de 17

pulgadas, ya que este tamao permita la visualizacin cmoda de la aplicacin de historias
medicas. Por otro lado, el teclado ms conveniente, con el fin de optimizar el espacio, result
ser tipo mini, con las siguientes dimensiones: 27 13 1 .
Para la transferencia de datos, se seleccion el modem de aba inalmbrico que ofreca
CANTV.
De esa manera, se constituy una solucin mucho ms eficiente a la propuesta inicial y con
menos restricciones, permitiendo realizar adaptaciones futuras. A continuacin se muestran los
equipos a implementar en el sistema de computacin:
Tarjeta D201GLY de INTEL.
Convertidor 12 V DC a Conector ATX.
Adaptador a disco flash.
Memoria Flash.
Memoria Ram de 4GB.
Monitor DC de 17 pulgadas.
Teclado Mini.
Modem Inalmbrico tipo USB.
67

________________________________________________________________________
Finalmente, la estructura del equipo de computacin se puede apreciar a continuacin:
SISTEMA DE
CONVERSOR DC ATX
ENERGA
Monitor
Tarjeta Madre
MEDICARRO
Figura 24. Configuracin de Sistema de Computacin
3.2.3. Seleccin de equipos de Sistema de Energa de Respaldo

Una vez seleccionados los componentes del equipo de computacin, se dio inicio a la
seleccin de equipos a implementar en el sistema de respaldo, segn procedimientos antes
mencionados.
Requerimientos de la carga: la siguiente tabla indica el consumo de cargas segn los datos
del fabricante:
Equipo
Potencia
Voltaje de
Corriente
Alimentacin
Pantalla
12 w
12 v (DC)
1A
200 w
120 v (AC)
2A
Tarjeta y equipos
perifricos
Tabla 3. Requerimientos de carga para Sistema de Respaldo de Energa

68
________________________________________________________________________
Para los clculos de la tarjeta de bajo consumo INTEL, se consider un factor de potencia
fp = 0,8
Considerando los datos de consumo, se estableci que la carga posea un requerimiento de
corriente total de ICARGA = 3 A. El estudio de los documentos tcnicos de los equipos, aport
informacin sobre la ventana de voltaje de los mismos, pudiendo concluir que la carga
permita valores de entrada 15% de su valor nominal de 12 V, de esa manera, la carga se
represent de la siguiente forma:
VMAX
VNOMINAL
VMIN
= 13,8
CARGA
CARGA
= 12
= 10,2
Figura 25. Requerimientos del Medicarro

Seleccin de la tecnologa, se realiz un estudio de las diversas tecnologas de bateras
disponibles y se seleccion la clase ms adecuada a las necesidades y prioridades:

Por razones de costos se seleccion la tecnologa Plomo cido, lo ms idneo hubiese
sido otra clase de bateras, pero sta se consider adecuada porque se trata del diseo de un
primer prototipo, una prueba de concepto, que trae consigo muchas oportunidades de mejoras
para las siguientes generaciones de Medicarros.
Nmero de celdas a implementar y voltaje final de descarga segn requerimientos de la
carga
Se inicia con la expresin:

/
69
________________________________________________________________________
Donde / = 2,27 , segn datos del fabricante. De esa manera:
6
El / se obtuvo mediante la siguiente relacin:
/ =
/ =
/ = 1,7 /
Este voltaje no se encontr en las tablas tcnicas, as que fue ajustado al valor ms cercano
en la escala de voltajes IEEE, / = 1,75 / .
Se determin la capacidad requerida para mantener a la carga operativa empleando modelos
de bateras de Plomo cido, cotizadas por INTELEC, empresa lder en el rea, tras
numerosas visitas. Se consideraron los factores de correccin pertinentes:
Todos los parmetros estimados permitieron modelar la carga de la siguiente manera:
V
1,75 V
I
3A
L
TAUT
Figura 26. Requerimientos del Medicarro
70
________________________________________________________________________
De los modelos cotizados por INTELEC, se seleccion inicialmente el modelo UPS12
350MR, (ver documento 11 del anexo) de acuerdo con los costos y tiempo de entrega,
posteriormente, se busc en sus tablas tcnicas, hasta localizar el correspondiente al
/ que cumpliera con los requerimientos 3 , como consecuencia, se obtuvo
el valor de = 24 horas.
A continuacin, se expres la capacidad segn el estndar IEEE:
=
La correspondiente a las condiciones IEEE es de 11 A:
= 11 8
= 88 .
Luego, se incorporaron los factores de correccin:
= 1,1 valor tpico
= 1 debido a que la temperatura tpica de una sala de emergencias es de 25 C
=1,25
Se estim la capacidad corregida, con el fin de garantizar que bajo condiciones de
temperatura, diseo y envejecimiento la batera todava pudiera ofrecer los requerimientos A.h
de la carga:
=
= 121 .
71
________________________________________________________________________
Como se sobre dimension la batera para que permitiera garantizar el suministro de
energa bajo condiciones adversas, se analiz si el modelo seleccionado inicialmente cumpla
con los nuevos requerimientos:
=
=
= 15,12
La batera UPS 12-350MR no poda suministrar la requerida, por lo tanto, se
procedi a buscar un modelo adecuado.
Seleccin de la batera a ser implementada en el sistema de respaldo de acuerdo con los
parmetros anteriormente determinados.

La batera UPS 12540 MR, tambin cotizada por INTELEC, cumple con los
requerimientos. A continuacin se presentan sus dimensiones:
Batera
27 cm
34 cm
18 cm
Figura 27. Dimensiones Batera UPS 12540 MR
Resulta conveniente mencionar que este modelo tiene fecha de entrega de 10 a 12 semanas,
segn documentos de la empresa, a diferencia del modelo inicial, que es de slo dos semanas.
A pesar de ello, resulta necesaria la batera seleccionada a fin de maximizar el desempeo, uso
y eficiencia del Medicarro.
72
________________________________________________________________________
Entre las ventajas ms importantes se encuentran las siguientes:
Mxima eficiencia de recombinacin de gases.
Montaje en cualquier orientacin.
Componente con certificacin UL, estndares Eurobatt, ANSI.
Diseo especial para mximo rendimiento en aplicaciones de UPS.
Adicionalmente, el equipo incluye:

Cables conectores interbloques.
Tornillera.
Garanta respaldada por CORPORACION INTELEC C.A., representante para Venezuela
de las bateras marca DYNASTY.
Seleccin del rectificador:
En primer lugar, se analizaron los requerimientos de energa:

= +

@ 80%
El tiempo de autonoma se obtuvo a partir de la relacin de Capacidad IEEE, a

pesar de que este estndar se calcul inicialmente con 8 horas de tiempo de autonoma, ste en
la implementacin ser mayor al esperado inicialmente debido a los sobredimensionamientos
realizados (este procedimiento se realiza en la prctica por las empresas del rea):
=
73
________________________________________________________________________
El consumo mximo de la carga era de 3A, y la capacidad final calculada era de 121 A.h:
= 40
En este sentido, la aplicacin se dise para que tuviera una autonoma de 40 horas.
El @ 80% se estim en 10 horas, ya que este es un valor tpico en las aplicaciones de
respaldo, segn la asesora de la empresa INTELEC. De esa manera, se pudo dimensionar el
rectificador:

+
@ 80%
= 17,4
Cuando se busc un rectificador de igual o mayor suministro de corriente, se seleccion
uno de 35 A, cotizado por INTELEC, con las siguientes dimensiones:
10 cm
40 cm
30 cm
Figura 28. Dimensiones de Rectificador
Como siguiente paso, se analizo la efectividad de implementar o no redundancia de

rectificadores en el sistema:
17,4
0,5 1
35
74
________________________________________________________________________
Es decir, que con un rectificador de 35 A se pudo cumplir fcilmente con el requerimiento
de 17,4 A, por lo tanto:
1
Sin aplicar redundancia, es decir 1+0, el suministro del rectificador sera de 35 A, de esa
manera el @ 80%
=

+
@ 80%
@ 80% = 4,5
Mientras que en el caso de redundancia 1+1, el suministro del rectificador sera de 70 A, de
esa manera el @ 80% = 2,14
Se concluy que para la constitucin del primer prototipo no resultaba imprescindible la
implementacin de redundancia, ya que no se justificaba la adquisicin de un rectificador
adicional para slo disminuir dos horas del tiempo de carga. El sistema rectificador
seleccionado fue 1+0, permitindole a la carga un tiempo de autonoma de 40 horas y tiempo
de carga de 4,5 horas.
Seleccin de Breakers para la Batera
Se calcul la corriente mxima que pudiera circular por esa lnea de conexin,
considerando que el valor mximo del rectificador es de 35A y el de la carga es de 3A:
= +
= 32
Luego:
= 1,25
= 1,25 32
= 40
75
________________________________________________________________________
El valor tpico comercial es de 40 A.
Seleccin de Breakers para la Carga, considerando el consumo mximo de la carga:
= 1,25
= 1,25 3
= 3,75
El valor tpico comercial ms cercano es de 5 A.
Seleccin de Breakers para la entrada del Rectificador
Para este caso, se consider un factor de potencia =0,8, ya que por esta lnea de conexin
circula corriente AC:
=
=
=
El valor de la eficiencia del equipo se tom de datos tcnicos aportados por la empresa
INTELEC ( =0,9). De esa forma:
= 6
Finalmente se estim el
= 1,25
= 7,5
76

________________________________________________________________________
Seleccin de Breakers para la salida del Rectificador, considerando que el suministro
mximo es de 35A:
= 1,25
= 1,25 35
= 43,75
En este sentido, se obtuvo el sistema de energa de respaldo con la configuracin que se
puede apreciar en la figura 21. A continuacin se muestran los equipos a implementar en el
sistema de respaldo de energa:
Equipo
Cantidad
Caracterstica
Tecnologa: Plomo cido

Batera
Modelo: UPS 12-540 MR

Voltaje: 12 v (DC)
Rectificador
120 v (AC) / 12 v (DC)

Capacidad: 35 A
Breakers
40 A
5 A
50 A
10 A
Tabla 4. Equipos de Sistema de Respaldo
77
________________________________________________________________________
3.2.4. Seleccin de Sistema de Registro Mdico Electrnico

Considerando los requerimientos de software analizados, lineamientos gubernamentales de
implementacin y desarrollo de software en Venezuela, as como complejidad del sistema
hospitalario, se sugiri el programa Care2x, por ser el sistema de informacin para el manejo
de historias clnicas ms completo, robusto, escalable, adaptable, modificable y sencillo de los
considerados para el anlisis.
Otra ventaja de este sistema de manejo de historias clnicas, es que permite ser
implementarlo con diversos servidores y bases de datos, lo que le otorga gran facilidad;
durante el diseo de la solucin, se empleo el servidor Apache y de la base de datos MySQL.
Resulta importante destacar que el Medicarro puede ser empleado con otro sistema de
manejo de historias clnicas, si los entes gubernamentales encargados de la seleccin
consideran otro software.
3.2.5. Adaptaciones propuestas al Sistema de Registro Mdico Electrnico

Con el objetivo de adaptar el software del Care2x al manejo de historias clnicas en el
sistema hospitalario nacional, en caso de ser implementado, se determinaron una serie de
modificaciones que son necesarias.
En cuanto a su programacin, result necesario proponer la implementacin de la
funcionalidad de red, para ello se debe implementar la programacin mediante sockets, para la
comunicacin entre el sistema del Medicarro y el servidor, de forma tal que puedan transmitir
los datos cargados en el sistema y garantizar el acceso a ms de un Medicarro al servidor.
En este sentido, result valioso haber manipulado, analizado y estudiado el sistema del
proyecto Red-HL7, cuyo objetivo principal fue justamente el desarrollo de esta funcionalidad
78
________________________________________________________________________
en especfico; manejando para ello, una versin libre del estndar HL7, para darle este formato
a la informacin transmitida.
Otro factor sugerido fue la modificacin de la Unidad de Diseo Interactivo, ya que la
interfaz de usuario debe ser amigable y proporcionar las herramientas a la vista, para que el
sistema pueda ser manejado por el profesional a cargo del Medicarro; en este caso tambin se
puede tomar de referencia el sistema Red-HL7.
El contenido del mdulo de registro mdico Care2x debera ser modificado, para que
contenga una recopilacin de los datos realmente necesarios, de todos los formatos empleados
actualmente para esta labor. En este sentido, se propuso un formato para ser integrado al
sistema Care2x (ver Anexo 10.12.)
El sistema de manejo de historias clnicas debe poseer mdulos que permitan la
visualizacin de datos para realizar estadsticas de atencin, enfermedades consultadas, estatus
de pacientes (activos o pasivos), camas desocupadas, pacientes vistos por mdico, as como
por turno.
3.2.6. Seleccin de la Estructura Fsica

El CENIT otorg un mdulo de computacin desarrollado con anterioridad, denominado
Infopunto. Actualmente se emplea como punto de acceso a internet en reas externas, en el
marco de campaas de familiarizacin y promocin de herramientas tecnolgicas.
Este equipo posee una estructura robusta, especialmente diseada para operar en
condiciones de intemperie, resistir cadas y movimientos bruscos; dispone de reas diseadas
para los equipos de computacin en su interior.
A continuacin, se presenta el mdulo de computacin (Infopunto) convertido en el primer
prototipo del Medicarro a travs de la adaptacin de ruedas, acorde al peso del equipo:
79
________________________________________________________________________
Foto 11. Medicarro I
El equipo obtenido exhibi ciertas caractersticas requeridas para el Medicarro, sin

embargo, result muy pesado para desplazarlo, debido a que su objetivo anterior era prestar
servicio en un lugar fijo y no en movimiento. Adems, no posea el espacio suficiente para
todos los equipos requeridos. En este sentido, se descart su empleo para el Medicarro y se
determinaron las diferentes adaptaciones en virtud de poder obtener una estructura adecuada.
3.2.7. Adaptaciones propuestas a la Estructura Fsica

Con el objetivo de proponer el diseo del Medicarro acorde a los requerimientos, se
procedi a recopilar las caractersticas de inters del Infopunto y algunos equipos vistos
80
________________________________________________________________________
durante las visitas al hospital de referencia, que si bien no se encuentran orientados al mismo
objetivo, ya estn diseados para operar en el ambiente hospitalario. Dichas caractersticas se
combinaron con las dimensiones de los equipos a implementar y como consecuencia de ello,
se obtuvo el diseo que a continuacin se muestra:
45 cm
35 cm
50 cm
15 cm
35 cm
12 cm
50 cm
45 cm
Figura 29. Diseo de Medicarro
Como se puede apreciar posee ruedas que le permitiran movilidad, un compartimiento para
colocar los equipos seleccionados de computacin y energa de respaldo, una gaveta, un
cilindro tipo pistn, en la parte superior el monitor, teclado, mouse, cmara y cornetas y
aunque no se pueda visualizar, posee en la parte posterior un cable retrctil para conectarlo a la
toma AC durante su modalidad de carga. Por ltimo, el material sugerido es el aluminio o
alguna de sus aleaciones, ya que es resistente, liviano y se produce en el pas.
81
________________________________________________________________________
3.2.7.1. Diseo estructural del Medicarro
El Medicarro debe poseer un diseo modular que le permita ser ensamblado y producido en
serie en el futuro, de manera eficiente y eficaz. Para la construccin del diseo propuesto se
localiz, se visit y se seleccion a la empresa La Vasconia, por ser pionera y lder por ms de
60 aos en el diseo y construccin de mobiliario mdico quirrgico y de laboratorio.
En un futuro, se proyecta que la produccin pueda ser realizada en la lnea de innovacin
que posee el CENIT en su parte posterior.
3.2.7.1.1. Mdulo Superior

El mdulo superior se encuentra diseado para que la inclinacin de la pantalla pueda ser
ajustada acorde al operador del Medicarro, permitiendo tambin, que en caso de traslado la
misma pueda ser cerrada y quede el equipo sin partes vulnerables expuestas, tal como se
muestra en las siguientes figuras:
Figura 30. Mdulo Superior del Medicarro

82
________________________________________________________________________
Figura 31. Pantalla del Medicarro Posicin I
Figura 32. Pantalla del Medicarro Posicin II
Cabe destacar que el pistn que ensambla el mdulo superior e inferior puede ser
manipulado y hacer que el modulo superior suba o baje, de acuerdo a la posicin del operador
del equipo (de pie o sentado).
83
________________________________________________________________________
3.2.7.1.2. Mdulo de Computacin
El mdulo de computacin se ubic en la parte superior del cajn inferior del equipo, tal
como se muestra a continuacin:
Mdulo de Computacin
18 cm
50 cm
Figura 33. Mdulo de Computacin
3.2.7.1.3. Mdulo Energa de Respaldo

El mdulo de energa de respaldo se ubic en la parte inferior del cajn del equipo, tal
como se muestra a continuacin:
50 cm
Mdulo de Computacin
Batera
Rectificador
30 cm
18 cm
Figura 34. Mdulos de Energa de Respaldo y Computacin
La posicin de todos los equipos fue determinada por la bsqueda de la optimizacin del
espacio.
84
CAPITULO IV: FUNCIONAMIENTO DEL MEDICARRO

________________________________________________________________________
CAPITULO IV:
FUNCIONAMIENTO DEL MEDICARRO
Considerando las estadsticas de atencin del hospital de referencia, se recomend para el

funcionamiento optimo del sistema de manejo de historias clnicas, el empleo de tres
Medicarros para la sala de emergencias, as como la constitucin de un Centro de Asistencia
Tcnica, con un empleado para cada turno de ocho horas, cubriendo as las 24 horas de
funcionamiento y respaldo, en caso de eventualidades.
Se sugiri que el procedimiento de manejo de historias clnicas en el rea de emergencias
se encuentre estructurado de la siguiente manera:
Se recibe el paciente que ha de ser atendido en el servicio, se busca su ficha electrnica en
el Medicarro, a travs de su sistema de manejo de historias clnicas Care2x. Si no la posee
se registra la ficha electrnica, solicitndole los datos de identificacin, antecedentes,
motivo de la consulta, examen fsico y diagnostico presuntivo. En caso de que el paciente
sea menor de edad, se le toman los datos personales del padre, la madre o el representante.
Cada acceso al sistema debe realizarse introduciendo un nombre de usuario y una clave que
otorgar determinados beneficios al operador y en cada modificacin se almacena el
operador que la realiz.
Se abre una ficha en papel, en caso de que el hospital de referencia desee mantener un
sistema de respaldo fsico en la institucin.
Se agregan los resultados de los exmenes realizados al paciente.
En caso de que el paciente sea para hospitalizar, se inicia el procedimiento de procura de
cama.
Si un paciente necesita ser hospitalizado en el rea de emergencia, el procedimiento

sugerido es el siguiente:
85

________________________________________________________________________
Se reciben admisiones de pacientes que vienen por emergencia.
Se revisa la ficha electrnica del paciente a hospitalizar.
Se llenan las seis fichas de hospitalizacin del paciente (ver formato 7 del anexo) para ser
distribuidas de la siguiente forma: panel de hospitalizacin, ndice de paciente en la pared,
boleta, informacin, cuerpo y fichero para informacin; cada una de ellas deben llevar los
datos personales, servicio, habitacin, diagnostico, inciales del tcnico que elabor su
ingreso. En el momento en que el hospital de referencia entero, cuente con un sistema de
manejo de historias electrnicas, este procedimiento no ser necesario.
El paciente es hospitalizado.
En esta seccin, se agrega la informacin de egreso del paciente.
En este sentido, se optimiza el procedimiento de atencin del hospital de referencia, a

travs del Medicarro, reduciendo los recursos de papelera y atendiendo a los pacientes de
acuerdo con sus antecedentes e historial clnico.
El personal deber ser capacitado para la manipulacin del equipo, mediante talleres
gratuitos promovidos por el CENIT, en conjunto con el Ministerio del Poder Popular para la
Salud.
La informacin es accedida a travs del Medicarro por medio de la arquitectura cliente
servidor y programacin con sockets, que permite mltiples accesos, la pasarela de informacin
ser la compaa CANTV, hasta llegar al servidor y la base de datos, tal como se aprecia a
continuacin:
86

________________________________________________________________________
Atencin 1
CANTV
Atencin 2
Servidor
Base de
datos
Atencin 3
Medicarro
Figura 35. Funcionamiento del Medicarro
El Medicarro debe cargarse cada 40 horas de operacin, conectndose a un terminal AC

disponible en la sala de emergencia y puede ser retirado de la misma luego de 4,5 horas. Se
recomienda que cada Medicarro sea activado en momentos distintos, para que mientras uno se
encuentre en recarga, los dems puedan prestar servicio.
CAPITULO V: PLAN DE ASISTENCIA TCNICA DEL MEDICARRO
87
________________________________________________________________________
CAPITULO V:
PLAN DE ASISTENCIA TCNICA DEL

MEDICARRO
Dada la importancia de mantener activo el sistema del Medicarro y de minimizar los

tiempos de respuesta en caso de fallas, se ha propuesto un completo Plan de Asistencia
Tcnica para el sistema del Medicarro del Centro de Referencia. En este plan de asistencia, se
realiza un recorrido modular de las posibles fuentes de errores. Para ello, se estudian los
niveles fsicos y lgicos.
Se propone que el soporte tcnico del Medicarro cuente con atencin 7x24 (7 das a la
semana, 24 horas al da), con un empleado por turno de ocho horas, capacitado y con todos los
repuestos para atender cualquier eventualidad.
5.1. PROCEDIMIENTO DE REPORTE Y SEGUIMIENTO DE FALLAS

Los pasos a seguir para realizar un requerimiento al Centro de Asistencia Tcnica, estn
reflejados en dos aspectos fundamentales: Solicitud de Servicio y Prioridades de Atencin.
5.2. SOLICITUD DE SERVICIO

Las solicitudes de servicio o reportes de fallas, deben ser realizados directamente al Centro
de Asistencia Tcnica.
Al momento de reportar de incidente, el profesional a cargo del Medicarro deber
suministrar al Tcnico los siguientes datos (y otros que la operacin requiera): serial,
ubicacin fsica y falla que presenta el equipo. A partir de entonces, el responsable del
Medicarro ser el tcnico a cargo y suministrar un nmero de incidente y fecha / hora de
88

________________________________________________________________________
registro. El nmero permitir el seguimiento del incidente y la fecha / hora para efectos de
medicin de los tiempos de respuesta.
La atencin podr efectuarse en el lugar en el que opera el Medicarro si se puede, sino el
equipo deber trasladarse a un rea dispuesta para ello, en caso de que no se logre resolver el
problema, ste ser escalado a un especialista de campo.
5.3. NIVELES DE ESCALAMIENTO DE FALLAS

El Plan de Asistencia Tcnica del Medicarro contempla los siguientes niveles de fallas:
Nivel 1: El Sistema de Energa de Respaldo no funciona correctamente.
Nivel 2: El Medicarro no opera correctamente, el equipo de registros mdicos no funciona.
Nivel 3: El desempeo del sistema del Medicarro es deficiente o no funciona
correctamente.
5.4. PLAN DE ASISTENCIA TCNICA DE NIVEL FSICO DEL MEDICARRO

A continuacin se muestra una lista de chequeo, que pueden dar una visin ms especfica
del problema que se puede estar presentando en el equipo. El carcter de esta lista de chequeo
es genrico y se refiere a verificaciones del nivel de fallas 1 y 2:
Descripcin de la Prueba
Resultado
Chequeo Modalidad de Recarga
Sistema AC conectado: Se encuentra en buen estado el cable de Pas __

alimentacin ubicado en la parte posterior?
Fall __
Sistema AC conectado: Las tomas de electricidad AC se encuentran Pas __

debidamente conectadas al terminal de poder del Medicarro?
Fall __
89

________________________________________________________________________
Sistema AC conectado: Se encuentra la alimentacin AC disponible Pas __
Fall __
para encender el equipo?

Chequeo Modalidad de Autonoma
Sin Alimentacin DC conectada: Se encuentran en buen estado los Pas __

cables que interconectan el sistema de alimentacin de respaldo?
Fall __
Sin Alimentacin DC conectada: Estn los cables debidamente Pas __

Fall __
asegurados y haciendo contacto elctrico?
Sistema DC conectado: El sistema de alimentacin de respaldo Pas __

Fall __
12Vdc se encuentra debidamente conectado?
Sistema DC conectada: Se encuentran los cables de alimentacin Pas __

Fall __
conectados a las fuentes que proveen la alimentacin?
Sistema DC conectada: La energa DC logra mantener encendido el Pas __

Fall __
Medicarro el tiempo de autonoma estimado?

Chequeo Funcionalidad del Medicarro
El procesador, disco y memoria del Medicarro estn correctamente Pas __

Fall __
colocados en sus respectivos compartimientos?
Se encuentran bien conectados todos los dispositivos perifricos tales Pas __

como: mouse, teclado, monitor?
Fall __
Se prendi el equipo luego de presionar el botn de encendido?
Pas __
Fall __
El LED de Power On se encuentra encendido?
En el proceso de Boot del sistema puede verificar si se reconoce el Pas __

disco duro
Fall __
Se encuentran debidamente configurados los parmetros de los Pas __

dispositivos instalados en el Medicarro? Para ello, ingrese al SETUP Fall __
luego de encender el equipo.
El sistema operativo arranca correctamente luego de encender el Pas __
equipo?
Fall __
Tabla 5. Lista de General chequeo de problemas de nivel 1 y 2 del fallas
90
________________________________________________________________________
En este sentido, puede resultar necesario reemplazar algunos de los dispositivos que
integran el equipo.
El Plan de Asistencia Tcnica del Medicarro, en materia de diagnstico a nivel 1 y 2 de
fallas, se bas en los problemas ms comunes y de mayor impacto que puede generar una falla
en el equipo.
5.5. PLAN DE ASISTENCIA TCNICA DE NIVEL DE APLICACIN DEL

MEDICARRO
Dada la importancia de estas aplicaciones inherentes al sistema de manejo de historias
clnicas del Medicarro, se muestra un plan de asistencia tcnica que permite diagnosticar y
solucionar algunos de los problemas ms comunes en esta materia.
No se puede visualizar la informacin del SETUP del equipo: El no poder ingresar al
Setup del equipo es de suma gravedad, probablemente haya un problema asociado con la
memoria ROM del equipo, ya que sta suele almacenar la configuracin del sistema o
proceso de arranque, el chequeo inicial del sistema, carga del sistema operativo y diversas
rutinas de control de dispositivos de entrada/salida. sta informacin no se pierde al apagar
la computadora y se puede cambiar por medio del programa SETUP del equipo. Partiendo
de esto, se presentan algunas de las posibles causas a estudiar al presentarse el problema:
Problemas con el cableado dentro del equipo.
Problemas asociados a la ROM del equipo
La aplicacin de manejo de historias clnicas Care2x no funciona: el primer paso es

verificar que se encuentra iniciado el servidor y la base de datos del sistema del Medicarro,
as como la conexin de CANTV.
91
________________________________________________________________________
No hay conexin de CANTV: el tcnico a cargo debe comunicarse con la compaa que
suministra la conexin para resolver o esperar por la resolucin de la falla.
92
CAPITULO VI: MS ALL DEL MEDICARRO

________________________________________________________________________
CAPITULO VI:
MS ALL DEL MEDICARRO
El desarrollo del diseo del Medicarro rompe fuertemente los paradigmas y concepciones
preestablecidas, su valor agregado ms importante es el hecho de que puede ser escalable y
adaptable a diferentes entornos del sistema hospitalario, de manera que la atencin mdica
pueda brindar un nivel de calidad sin precedentes en la historia.
Un ejemplo de ello es el Medipunto, producto de la iniciativa de la Fuerza Area, el
Ministerio del Popular para la Ciencia y Tecnologa, Ministerio del Poder Popular para la
Salud y el CENIT, para incorporar soluciones tecnolgicas con marca venezolana en
ambulatorios rurales, elevando as la calidad de vida de la poblacin que acude a ellas.
De esa forma, se desarrollo el diseo de un dispositivo de Telemedicina para centros rurales
basado en la adaptacin de un sistema de Circuito Cerrado de Televisin (CCTV) como
plataforma piloto, con cmaras implementadas en diferentes equipos de diagnostico y
exploracin mdica, con la finalidad de enviar imgenes y videos de exmenes mdicos
tomados con estos equipos desde los ambulatorios rurales a un centro hospitalario para labores
de interconsulta mdica.
El diseo de su estructura fsica, as como funcional fue desarrollada en conjunto con el del
Medicarro, de manera que ambos equipos pudieran ser fabricados iguales en apariencia,
facilitando los procesos de produccin en serie, pero diferencindose en su interior, por lo
equipos a implementar.
Por otro lado, resulta importante destacar que el Medicarro tambin se proyecta como
plataforma de comunicacin para otros equipos mdicos, pudiendo enriquecer la informacin
de la historia clnica del paciente anexando directamente imgenes y vdeos de exmenes de
equipos de diagnostico y exploracin mdica, permitiendo as que el mdico pueda acceder a
la informacin correspondiente al paciente y a los exmenes realizados al mismo:
93
CAPITULO VI: MS ALL DEL MEDICARRO

________________________________________________________________________
Electrocardiogramas (ECG), informacin proveniente de monitores de signos vitales, entre

otros.
Otra modalidad de operacin previstas para un futuro son las listas de trabajo, se
presentaran si el paciente es remitido a otro servicio, por ejemplo radiologa; el sistema de
historias clnicas podr enviar un aviso al profesional a cargo (la unidad destino debe tener
acceso al sistema del Medicarro), especificndole los datos del paciente remitido. En
consecuencia, cada unidad conectada al sistema del Medicarro podr llevar un registro de los
pacientes atendidos. En este sentido, se conformara una gestin hospitalaria de avanzada.
CENTRO
Figura 36. Modalidad de Listas de Trabajo
Para finalizar, una ampliacin posible sera la incorporacin de equipos detectores de

huellas digitales, que actualmente son empleados para los procesos electorales, de manera que
pueda servir de identificador para pacientes inconscientes que lleguen a una institucin de
salud.
94
CAPITULO VII: ESTUDIO ECONMICO

________________________________________________________________________

7.1. ESTUDIO DE COSTOS DEL PROYECTO
A continuacin se muestra un estudio econmico del proyecto de diseo de un equipo para
el manejo de Historias Clnicas Electrnicas en el Sistema Hospitalario Venezolano. Este
anlisis, permitir entender de manera ms fcil cuales son los beneficios en materia de
bienestar social que se obtienen.
Los datos mostrados a continuacin incluyen los costos de los equipos necesarios para
implementar el diseo del Medicarro:
Equipo
Precio BsF
Batera Tecnologa: Plomo cido Modelo: UPS
1.396,00
12-540 MR Voltaje: 12 v (DC)

Rectificador120 v (AC) / 12 v (DC) Capacidad: 35 A
1.000,00
Breaker 50 A
70,93
Breaker 40 A
70,93
Breaker 10 A
32,23
Breaker 5 A
32,23
Tarjeta D201GLY de INTEL
187,05
Convertidor 12 V DC a Conector ATX
83,85
Adaptador a disco flash
23,47
95

________________________________________________________________________
Memoria Flash
27,84
Memoria Ram de 4GB
90,30
Monitor DC de 17 pulgadas
700,00
Teclado Mini
50,00
Modem Inalmbrico tipo USB (equipo y renta de 12
1.593,05
meses)
Sub Total Equipos / Medicarro
5.357,88
Tabla 6. Equipos necesarios para implementar el diseo del Medicarro
Este subtotal obtenido se refiere slo a los equipos, por consiguiente, se debe tomar en
consideracin los materiales y mano de obra de la La Vasconia, la cual tendr a su cargo la
elaboracin de la estructura externa del Medicarro:
Servicio
Precio BsF
Construccin de la estructura externa del Medicarro
5.000,00
Sub Total Equipos
5.357,88
Total Costo / Medicarro
10.357,88
Tabla 7. Costo del Medicarro
96

________________________________________________________________________
Al comparar los costos del prototipo diseado, con los del equipo DELL considerado de
manera referencial (6.944,48 Bs.F.), la diferencia resultante no es significativa, tomando en
cuenta que el Medicarro es el primer prototipo y no el equipo final para produccin en serie.
En este sentido, los costos del Medicarro pueden ser reducidos en gran medida a travs de
numerosas modificaciones, entre las que se destacan: optimizacin el proceso de produccin
en serie, ejecutndolo en la lnea de innovacin del CENIT y establecimiento de alianzas
estratgicas entre el CENIT y CANTV, para que tanto el equipo para transmisin de datos,
como su renta bsica queden exonerados de pago.
7.2. RELACIN COSTO BENEFICIO

El desarrollo de un equipo de manejo de historias clnicas constituye un proyecto de orden
social, por consiguiente, un aspecto importante en el estudio econmico es el valor de la
relacin Beneficio/Costo, ya que es la forma de cuantificar de alguna manera los beneficios
que obtiene la sociedad. La relacin Costo Beneficio viene dado por la razn entre los
beneficios del proyecto y los costos del mismo:
R B/C =
BENEFICIOS
COSTOS
Cabe destacar, que un tiempo prudencial de anlisis para calcular el R B/C considerando el
tiempo necesario para medir el xito del proyecto y tomando en cuenta la depreciacin
tecnolgica de los equipos a usar, es de un estimado de 6 meses a 2 aos.
Como primer paso se establecen los beneficios obtenidos con la ejecucin del proyecto y se
clasifican entre directos e indirectos:
Beneficios Directos: Son los que representan el propsito principal del proyecto, en el caso
del Medicarro, los beneficios directos obtenidos fueron:
97

________________________________________________________________________
Optimizacin del tiempo de registro de historias clnicas de pacientes, la forma de evaluarlo

es
Reduccin de gastos de papelera, la forma de evaluarlo es
Beneficios indirectos: Beneficios que no estaban estimados en un principio y vienen dados

de manera colateral, entre los que se destacan:
Reduccin de Papelera en otras reas como consecuencia del poco uso de papel en
emergencias.
Incremento del nmero de pacientes atendidos: al invertir menos tiempo en cada paciente,
existe la posibilidad de atender mayor cantidad de individuos.
Modernizacin del sistema hospitalario: la implementacin del Medicarro dotara a las
instituciones de un equipo con tecnologa actual y potencial de ampliacin.
Incremento de la calidad atencin: los pacientes estaran siendo atendidos con mayor
tecnologa y simplicidad, generando familiarizacin tecnolgica.
Menos impacto ambiental debido a la contaminacin ambiental.
En el caso de la reduccin de papel y artculos relacionados, se realiz un estimado

considerando las estadsticas de atencin del hospital de referencia y los procedimientos de
atencin propuestos, en este sentido:
De cada 100 personas que ingresan al rea de emergencias, 30 son atendidas en la sala
inmediata y dadas de alta, de manera que las 70 restantes son distribuidas en las diferentes sub
reas acorde con su estado y enfermedad, siendo necesario realizar exmenes mdicos; al
final, aproximadamente 30 necesitan ser hospitalizadas.
Antes de la ejecucin del proyecto: Considerando los protocolos de atencin mencionados
y formatos de atencin, se emplean aproximadamente 900 hojas de papel slo para el rea de
emergencia, distribuidas de la siguiente manera:
98

________________________________________________________________________
Emergencia: se emplean las fichas 1, 2, 3 y 4 del anexo, de una pgina cada una a
excepcin de la ficha 2, que posee 2 pginas:
100
Pacientes X
= 500 Hojas
Se realiza por lo menos un examen por persona:
70
Pacientes X
= 70 Hojas
Admisin: se emplean las fichas 5, 6, 7, 8, 9 y 10 del anexo, de una pgina cada una a
excepcin de la ficha 6, que posee 6 pginas:
30
Pacientes X 11
= 330 Hojas
Total 900 Hojas
Despus de la ejecucin del proyecto: Considerando que se atenderan en la sala de

emergencia 100 personas por Medicarro y que no se eliminara por completo el registro en
papel, se obtendra:
99

________________________________________________________________________
Emergencia: se empleara una ficha de registro de una pgina:
100
Pacientes X
= 100 Hojas
Se cargara al sistema del Medicarro los resultados de exmenes:
70
Pacientes X
= 0 Hojas
= 30 Hojas
Admisin: se empleara una ficha:
30
Pacientes X
Total 130 Hojas

De todo esto, resulta evidente que la ejecucin del proyecto es sumamente beneficiosa tanto
en el rea econmica, como ambiental, ya que la reduccin de papel es considerable (770
hojas).
Por otro lado, se realiz estimacin en cuanto a la inversin total necesaria en el hospital de
referencia, para ello se estimaron los precios de los equipos que prestan servicio actualmente y
se compararon con los necesarios para la ejecucin del proyecto:
100

________________________________________________________________________
Sistema de Manejo
Costos
Sistema de Manejo
de Historias Clnicas de Historias Clnicas
Inversin
Tradicional
Medicarro
50.000,00 Bs.F.
31.073,64 Bs.F.
Tabla 8. Inversin del Medicarro
En este sentido, el sistema del Medicarro resulta ms conveniente que el empleo de

archivos y Kardex.
A continuacin se comparan los costos de mantenimiento antes y despus de la ejecucin del
proyecto, considerando que todos los costos fueron proyectados suponiendo un ao consecutivo
del sistema del Medicarro:
Sistema de Manejo de
Sistema de Manejo de
Historias Clnicas
Historias Clnicas
Tradicional
Medicarro
Costos
Bs.F / Mes
Papelera
Bs. / Ao
(Papel,
impresin y artculos
relacionados)
Bs. / Ao Bs.F / Mes
3.000,00
36.000,00
250,00
3.000,00
3.000,00
36.000,00
1.500,00
18.000,00
en el
rea de archivo
Profesionales
encargados
101

________________________________________________________________________
Mantenimiento
del
Sistema de Archivo
1.000,00
12.000,00
4.866,67
58.400,04
3.000,00
36.000,00
0,00
0,00
10.000,00
120.000,00
6.616,67
79.400,04
Actual
Papelera
en
otras
reas del Hospital

Total Costos
Tabla 9. Comparacin de Costos
De esa manera, la relacin beneficios costos se puede determinar:
120.000 . .
=
= 1,51
79.400,04 . .
>1
El anlisis del valor obtenido se realiza considerando lo siguiente:

RBC > 1 implica que los beneficios son mayores que los costos, entonces el proyecto es
aconsejable, puesto que no se incurrir en prdidas.
RBC = 1 implica que los beneficios son iguales que los costos, entonces el proyecto es
indiferente en materia de rentabilidad.
RBC < 1 implica que los beneficios son menores que los costos, entonces el proyecto no es
aconsejable.
En este sentido, el proyecto resulta recomendable, los beneficios econmicos son mayores
que los gastos de mantenimiento, al mismo tiempo que se obtienen numerosos beneficios no
cuantificables, que resultan favorables en gran medida para la poblacin y el ambiente.
102

________________________________________________________________________
Otro factor de inters es conocer en cuanto tiempo los beneficios obtenidos pueden saldar o
compensar el valor de la inversin realizada, para ello se consideran los beneficios netos, que
vienen dados por el ahorro que genera la disminucin de gastos de mantenimientos:
=
= 3.383,33 . .
Se divide la inversin total, entre los beneficios netos por mes, para obtener la cantidad de
meses que se necesitaran:
31.073,64
10
3.383,33 . .
No slo resulta rentable el proyecto, sino que con slo 10 meses de ejecucin, a travs del
ahorro generado, se completara el monto total invertido en un principio para la elaboracin
del proyecto.
CAPITULO VIII: CONCLUSIONES Y RECOMENDACIONES
103
________________________________________________________________________
CAPITULO VIII: CONLUSIONES Y RECOMENDACIONES

8.1. CONCLUSIONES
1. La estructura y condiciones del sistema hospitalario en Venezuela, no permiten la
implementacin de una solucin comercial para el manejo de historias clnicas; en su lugar,
el Medicarro puede abrir un nuevo captulo para la asistencia mdica, con la oportunidad de
optimizar su funcionamiento por medio de la modernizacin de su plataforma de atencin;
brindando mayor calidad de servicio a la poblacin que acude a las instituciones de salud.
En este sentido, las instituciones y niveles de atencin del Sistema Pblico Nacional de
Salud contaran ahora con una herramienta de integracin, para la transmisin de datos.
2. Existen sistemas de manejo de historias clnicas ya desarrollados en software libre, que se
encuentran disponibles para su implementacin en instituciones de salud, slo necesitan ser
adaptados de acuerdo a los requerimientos de historias clnicas y dotados de elementos de
seguridad, que garanticen que la informacin contenida en su interior se encuentra
protegida.
3. Result factible el diseo y dimensionamiento del sistema de respaldo de energa, con
equipo equipos existentes en el pas, brindando soluciones viables.
4. Se logr obtener slidos conocimientos sobre el funcionamiento del Sistema Hospitalario
de Venezuela, diagnstico de problemas y propuesta de solucin, adquiriendo herramientas
de desarrollo de sistemas de respaldo y sistemas de manejo de historias clnicas.
5. El proyecto resulta rentable; esto se verifico a travs del anlisis econmico. Se obtuvo un
retorno de inversin de 10 meses desde su puesta en funcionamiento. As como una
relacin beneficio costo que seala la viabilidad del mismo.
CAPITULO VIII: CONCLUSIONES Y RECOMENDACIONES
104
________________________________________________________________________
6. Ya demostrada la factibilidad tcnica del Medicarro, slo faltara demostrar su factibilidad
legal y poltica para la implementacin de un equipo de historias mdicas en Venezuela.
7. Uno de los aspectos ms valiosos del proyecto, reside en el aprendizaje interdisciplinario y
visin de futuras adaptaciones, que hicieron factible realizar el diseo del Medicarro con
ingeniera venezolana, de acuerdo a los requerimientos de hardware, software y
operatividad establecidos.
8.2. RECOMENDACIONES
Con el objetivo de optimizar el diseo, funcionamiento y posteriores ampliaciones del
Medicarro, se sugiere lo siguiente:
Estandarizar los protocolos de manejo de historias clnicas en las diversas instituciones de
atencin de salud, lo que facilitara brindar una solucin nica y reducir los costos de
integracin de sistemas diferentes.
Estandarizar el formato nico de historias clnicas.
Realizar adaptaciones legales a la historia clnica electrnica.
Crear redes locales que permitan el respaldo de emergencia para los datos de cada
institucin, en caso que la red amplia de CANTV sufra alguna falla o dao temporal; para
mejor calidad de atencin, cada hospital debe poseer una base de datos de sus pacientes
activos y pasivos.
Emplear bateras ms livianas de tecnologas ms avanzadas, que faciliten mejor
desempeo y mayor tiempo de autonoma en el Medicarro.
Implementar mayor nmero de rectificadores, para minimizar el tiempo de recarga del
equipo (aumentar redundancia).
Implementar dispositivos de proteccin LVD a la entrada de la batera para evitar descarga
excesiva.
105
CAPITULO IX: REFERENCIAS BIBLIOGRFICAS

________________________________________________________________________
CAPITULO IX:
[1]
REFERENCIAS BIBLIOGRFICAS
MANZOTTI [2005]. Estrategias durante la implementacin de un registro mdico

electrnico
en
un
hospital
de
comunidad,
[en
lnea].
Disponible
en:
http://www.sais.org.ar/Portals/2/SIS/SIS2007/Trabajos/10_Manzotti.pdf
[2]
MOHANTY. Hospital Information System in Medicare an Experience at Tata Main

Hospital, Jamshedpur, [en lnea]. Disponible en:
http://medind.nic.in/haa/t01/i1/haat01i1p70o.pdf
[3]
Mobile Medication Cart with Locking Side Bin, [en lnea]. Disponible en:
http://accessories.us.dell.com/sna/products/Cables_Hubs_Adapters/productdetail.aspx?
c=us&l=en&s=dhs&cs=19&sku=A1305141
[4]
Constitucin de la Repblica Bolivariana de Venezuela Publicada en 1999.
[5]
Reglamento Orgnico del Ministerio del Poder Popular para la Salud, [en lnea].
Disponible en:
http://www.mpps.gob.ve/ms/modules.php?name=Content&pa=showpage&pid=512
[6]
CASTRO. Historias Clnica, [en lnea]. Disponible en:

http://sefh.interguias.com/libros/tomo1/Tomo1_Cap2-2.pdf
[7]
Documento de la estructura y funciones del servicio de Registros Mdicos.

Suministrado por el Departamento del Historias Clnicas del Hospital Militar Dr.
Carlos Arvelo.
[8]
ATIENZA. Historia Clnica Informtica nica, [en lnea]. Disponible en:

http://www.medicin.com.ar/histocli.asp
[9]
Fbregas, J. Llors,
Sistemas de Informacin: Desarrollo, implementacin y
mantenimiento, Editorial Miro, pp. 5-12. (1991)

[10]
HL7, [en lnea]. Disponible en:

http://www.interfaceware.com/hl7.html?gclid=CNaXsOiY8ZACFRuhFQodwB4d1w
[11]
Ministerio del Poder Popular para las Telecomunicaciones y la Informtica, [en lnea].
Disponible en: www.softwarelibre.gob.ve/
106
CAPITULO IX: REFERENCIAS BIBLIOGRFICAS

________________________________________________________________________
[12]
Plan Nacional de Migracin a Software Libre, [en lnea]. Disponible en:

http://www.softwarelibre.gob.ve/index.php?option=com_content&task=view&id=20&
Itemid=79
[13]
PHP, [en lnea]. Disponible en: http://www.php.net/manual/es/
[14]
HORSTMANN, Cay, Core Java Volume I, Editorial Prentice Hall, pp 27-80. (2000)
[15]
ASP, [en lnea]. Disponible en:

http://msdn2.microsoft.com/en-us/library/aa286483.aspx
[16]
Ruby on Rails, [en lnea]. Disponible en: http://www.rubyonrails.org/
[17]
MySQL, [en lnea]. Disponible en: http://dev.mysql.com/doc/refman/5.0/es/index.html
[18]
Oracle Global Price List, [en lnea]. Disponible en:

http://www.oracle.com/corporate/pricing/technology-price-list.pdf
[19]
Oracle, [en lnea]. Disponible en: http://www.oracle.com/global/es/index.html
[20]
PostgreSQL, [en lnea]. Disponible en:

http://www.postgresql.org/docs/8.2/interactive/index.html
[21]
OpenHIS, [en lnea]. Disponible en: http://www.openhis.com.ar/
[22]
Programa del Proyecto HL7. Suministrado por el Departamento de Computacin de la

Universidad Simn Bolvar.
[23]
Care2x, [en lnea]. Disponible en: http://www.care2x.org/
[24]
CANTV, [en lnea]. Disponible en: http://www.cantv.com.ve/
[25]
Joskowicz, Jos., Redes de Datos, Tercera Edicin, Uruguay pp. 68-72, (2006).
[26]
Documento de Diseo, desarrollo y dimensionamiento de Sistemas de Respaldo.

Suministrado por INTELEC.
107
CAPITULO X: ANEXOS
________________________________________________________________________
CAPITULO X:
ANEXOS
108
CAPITULO X: ANEXOS
________________________________________________________________________
10.1.
FORMATO 1
109
CAPITULO X: ANEXOS
________________________________________________________________________
110
CAPITULO X: ANEXOS
________________________________________________________________________
111
CAPITULO X: ANEXOS
________________________________________________________________________
10.2.
FORMATO 2
112
CAPITULO X: ANEXOS
________________________________________________________________________
113
CAPITULO X: ANEXOS
________________________________________________________________________
10.3.
FORMATO 3
114
CAPITULO X: ANEXOS
________________________________________________________________________
115
CAPITULO X: ANEXOS
________________________________________________________________________
10.4.
FORMATO 4
116
CAPITULO X: ANEXOS
________________________________________________________________________
117
CAPITULO X: ANEXOS
________________________________________________________________________
10.5.
FORMATO 5
118
CAPITULO X: ANEXOS
________________________________________________________________________
119
CAPITULO X: ANEXOS
________________________________________________________________________
10.6.
FORMATO 6
120
CAPITULO X: ANEXOS
________________________________________________________________________
121
CAPITULO X: ANEXOS
________________________________________________________________________
122
CAPITULO X: ANEXOS
________________________________________________________________________
123
CAPITULO X: ANEXOS
________________________________________________________________________
124
CAPITULO X: ANEXOS
________________________________________________________________________
125
CAPITULO X: ANEXOS
________________________________________________________________________
126
CAPITULO X: ANEXOS
________________________________________________________________________
10.7.
FORMATO 7
127
CAPITULO X: ANEXOS
________________________________________________________________________
128
CAPITULO X: ANEXOS
________________________________________________________________________
10.8.
FORMATO 8
129
CAPITULO X: ANEXOS
________________________________________________________________________
130
CAPITULO X: ANEXOS
________________________________________________________________________
10.9.
FORMATO 9
131
CAPITULO X: ANEXOS
________________________________________________________________________
132
CAPITULO X: ANEXOS
________________________________________________________________________
10.10. FORMATO 10
133
CAPITULO X: ANEXOS
________________________________________________________________________
134
CAPITULO X: ANEXOS
________________________________________________________________________
10.11. SOCKETS EN PHP
<?php
/* Permitir que el script permanezca en espera de conexiones. */
set_time_limit(0);
/* Habilitar vaciado de salida implcito, de modo que veamos lo que
* obtenemos a medida que va llegando. */
ob_implicit_flush();
/*Se establece una direccin y puerto determinado*/
$direccion = '192.168.1.53';
$puerto
= 10000;
/* Se crea la conexin tipo TCP */

if (($sock = socket_create(AF_INET, SOCK_STREAM, SOL_TCP)) === false)
{
echo "socket_create() fall: motivo: " . socket_strerror(socket_last_error()) . "\n";
}
/*Se vincula la conexin con un puerto determinado*/
if (socket_bind($sock, $direccion, $puerto) === false)
{
echo "socket_bind() fall: motivo: " . socket_strerror(socket_last_error($sock)) . "\n";
}
/*Una vez establecida la conexin se espera por peticiones, el segundo parmetro indica el
*mximo de conexiones en cola que mantendr el sistema*/
if (socket_listen($sock, 5) === false)
{
echo "socket_listen() fall: motivo: " . socket_strerror(socket_last_error($sock)) . "\n";
135
CAPITULO X: ANEXOS
________________________________________________________________________
}
/*Se acepta la conexin y se genera un nuevo socket, que es que se encargar de la conexin
*establecida, para poder atender a las que estn en espera*/
do {
if (($mens_sock = socket_accept($sock)) === false)
{
echo "socket_accept() fall: motivo " . socket_strerror(socket_last_error($sock)) . "\n";
break;
}
/* Enviar instrucciones. */
$mensaje = "\nBienvenido al Servidor de Prueba PHP. \n" .
"Para salir, escriba 'salir'.".
"Para detener el servidor, escriba 'detener'.\n";
socket_write($mens_sock, $mensaje, strlen($mensaje));
do {
if (false === ($buf = socket_read($mens_sock, 2048, PHP_NORMAL_READ)))
{
echo "socket_read() fall: motivo: " . socket_strerror(socket_last_error($mens_sock))
. "\n";
break 2;
}
if (!$buf = trim($buf))
{
continue;
}
if ($buf == 'salir')
{
break;
136
CAPITULO X: ANEXOS
________________________________________________________________________
}
if ($buf == 'detener')
{
socket_close($mens_sock);
break 2;
}
$respuesta = "PHP: Usted dijo '$buf'.\n";
/* Se enva informacin a travs de las conexin */
socket_write($mens_sock, $respuesta, strlen($respuesta));
echo "$buf\n";
} while (true);
/* Finaliza la conexin */
socket_close($mens_sock);
} while (true);
socket_close($sock);
?>
137
CAPITULO X: ANEXOS
________________________________________________________________________
10.12. FORMATO DE HISTORIA CLNICA DIGITAL PROPUESTA
REPBLICA BOLIVARIANA DE VENEZUELA

DEPARTAMENTO DE EMERGENCIAS
FORMATO 1
Hospital:
Historia Clnica:
Hora:
Fecha:
Datos de Identificacin:
Apellidos:
Nombres:
Edad:
Militar:
Si es militar
Empleado: Si
No
Grado:
Familiar:
Si
No
Componente:
PBA:
Si
No
Si
No
Estado Civil:
Cdula:
Ocupacin:
Soltero:
Si
No
Casado:
Si
No
Viudo:
Si
No
Divorciado: Si
No
Religin:
Telfono:
Direccin:
Familiar:
Si
No
Si posee familiar:
Apellidos:
Nombres:
Telfono:
Tcnico de Registro:
Mdico Residente:
Mdico Interno:
Antecedentes:
Antecedentes Personales
1.1 ACV / AIT
1.24 Arritmias
1.2 Alergia
1.25 Parotiditis
138
CAPITULO X: ANEXOS
________________________________________________________________________
1.3 Amigdalitis
1.26 Pleuresa
1.4 Artritis
1.27 Quirrgicos
1.5 Asma
1.28 Rinofaringitis
1.6 Bilharzia
1.29 Rubeola
1.7 ETS
1.30 Sarampin
1.8 Bronquitis
1.31 Sfilis
1.9 Sinusitis
1.32 Diarreas
1.10 Catarros
1.33 T.B.C.
1.11 Chagas
1.34 Tifoidea
1.12 Chancros
1.35 Tosferina
1.13 Difteria
1.36 Traumatismos
1.14 Sndromes Disentricos
1.37 Vacunaciones
1.15 Hansen
1.38 Hepatitis
1.16 Influenza
1.39 SIDA / HIV
1.17 Enf. Infectocontagiosas
1.40 Diabetes
1.18 Helmintiasis
1.41 H T A
1.19 Neumona
1.42 Tipo Vivienda
1.20 Otitis
1.43 Grupo Sanguneo
1.21 Paludismo
1.44 Historia Laboral
1.22 Cardiopata Isqumica
1.45 Epilepsia
1.23 Insuficiencia Cardiaca
1.46 Otros
Antecedentes Familiares
2.1 Alergia
2.7 Enf. Renales
2.2 Artritis
2.8 Intoxicaciones
2.3 Cncer
2.9 Neuropsiquiatricas
2.4 Cardio-vasculares
2.10 Sfilis
2.5 Diabetes
2.11 T. B. C.
2.6 Enf. Digestivas
2.12 Otros
Hbitos Psicolgicos
3.1 Alcohol
3.8 Rasgos Personales
3.2 Chim
3.9 Sexuales
3.3 Deportes
3.10 Siesta
3.4 Drogas
3.11 Sueo
3.5 Tabaco
3.12 Ocupacin
3.6 Caf
3.13 Otros
3.7 Medicamentos
139
CAPITULO X: ANEXOS
________________________________________________________________________
Observaciones:
Consulta Actual:
Ubicacin:
Emergencia de Adultos:
Emergencia Peditrica:
Observacin
Observacin
Sala Inmediata de
Observacin
Trauma Shock I
Trauma Shock I
Sala de Asma
Trauma Shock II
Sala de Asma
Motivo de la Consulta:
Enfermedad Actual:
140
CAPITULO X: ANEXOS
________________________________________________________________________
Diagnostico de Admisin:
Examen Fsico:
Peso (Kg)
Talla(cm)
IMC
PAS(mmHg)
PAD(mmHg)
PAM(mmHg)
Temperatura
Glasgow
(C)
Observaciones:
Diagnostico:
141
CAPITULO X: ANEXOS
________________________________________________________________________
Intervencin Quirrgica:

Sobre Historias Clinicas

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Sobre Historias Clinicas

Transféré par

Droits d'auteur :

Formats disponibles

UNIVERSIDAD SIMN BOLVAR

Decanato de Estudios Profesionales

Diseo de un equipo para el manejo de Historias Clnicas Electrnicas en el

Sartenejas, enero de 2008

UNIVERSIDAD SIMN BOLVAR

Diseo de un equipo para el manejo de Historias Clnicas Electrnicas en el

INFORME FINAL DE CURSOS EN COOPERACIN TCNICA Y DESARROLLO

UNIVERSIDAD SIMN BOLVAR

Aprobado con mencin: X

Al Profesor Ricardo Silva, por su apoyo incondicional.

Planteamiento del problema ___________________________________________________ 1

Descripcin del Proyecto ______________________________________________________ 2

Estructura del Informe _______________________________________________________ 7

CAPITULO II: FUNDAMENTOS _____________________________________________ 9

Sistema Hospitalario de Venezuela______________________________________________ 9

Referencia de Centro de Salud Asistencial ______________________________________ 15

Conceptos bsicos de Registros Mdicos Electrnicos adaptados a Sistemas de Informacin

Universidad Simn Bolvar

Hildemar Celeste Amaro Arreaza

Requerimientos y lineamientos de Desarrollo e Implementacin de Software medico en

Herramientas disponibles para Desarrollo de Registros Mdicos Electrnicos adaptados a

Sistemas de Informacin __________________________________________________________ 27

Revisin de Sistemas de Registros Mdicos Electrnicos disponibles _________________ 32

Conceptos bsicos de Redes de Transmisin de Datos para Sistemas de Registros Mdicos

Electrnicos en Venezuela _________________________________________________________ 35

Sistema de Energa de Respaldo _______________________________________________ 39

Hildemar Celeste Amaro Arreaza

CAPITULO III: DISEO Y DESARROLLO DEL MEDICARRO ___________________ 59

MEDICARRO: Estructura General ___________________________________________ 61

Mdulo Superior _______________________________________________________ 81

Mdulo de Computacin _________________________________________________ 83

Mdulo Energa de Respaldo _____________________________________________ 83

CAPITULO IV: FUNCIONAMIENTO DEL MEDICARRO ________________________ 84

Procedimiento de Reporte y Seguimiento de Fallas _______________________________ 87

Solicitud de Servicio _________________________________________________________ 87

Niveles de Escalamiento de Fallas _____________________________________________ 88

Plan de Asistencia Tcnica de Nivel Fsico del Medicarro _________________________ 88

Hildemar Celeste Amaro Arreaza

Plan de Asistencia Tcnica de Nivel de Aplicacin del Medicarro ___________________ 90

CAPITULO VI: MS ALL DEL MEDICARRO ________________________________ 92

Estudio de Costos del Proyecto ________________________________________________ 94

Relacin Costo Beneficio _____________________________________________________ 96

CAPITULO VIII: CONLUSIONES Y RECOMENDACIONES ___________________ 103

Conclusiones ______________________________________________________________ 103

Recomendaciones __________________________________________________________ 104

CAPITULO IX: REFERENCIAS BIBLIOGRFICAS ___________________________ 105

Universidad Simn Bolvar

Hildemar Celeste Amaro Arreaza

Implementacin de un Sistema de Historias Clnicas Electrnicas en India __ 4

Voltaje Nominal de batera de Plomo-cido __________________________ 50

Requerimientos de carga para Sistema de Respaldo de Energa ___________ 67

Equipos de Sistema de Respaldo ____________________________________ 76

Lista de General chequeo de problemas de nivel 1 y 2 del fallas ___________ 89

Equipos necesarios para implementar el diseo del Medicarro ___________ 95

Costo del Medicarro ______________________________________________ 95

Inversin del Medicarro _________________________________________ 100

Comparacin de Costos __________________________________________ 101

Universidad Simn Bolvar

Hildemar Celeste Amaro Arreaza

Care2x HIS ____________________________________________________ 35

Transmisin ADSL ______________________________________________ 37

Distribucin de Servicios en ADSL __________________________________ 38

Sistema paralelo en operacin normal _______________________________ 41