Resumen de Historia Clínica Informática



Presentado como Trabajo monográfico final en el

CURSO DE ORGANIZACIÓN Y ADMINISTRACIÓN
DE SERVICIOS DE SALUD




Dr. LOIÁCONO FRANCISCO LEANDRO

ABRIL de 1998










PROYECTO :
RESUMEN DE HISTORIA CLINICA INFORMATICA

Sumario: Se presentan a continuación el estado actual referido a la recolección de datos y la dinámica de dichos procesos. Se propone el cambio hacia un registro electrónico de datos que facilite la disponibilidad, seguridad y efectiva utilización de los mismos con fines Epidemiológicos en forma oportuna.


ANÁLISIS DE SITUACIÓN ACTUAL

Bases de Datos Existentes:
En nuestro medio los Sistemas de recolección de datos contemplados son los siguientes:
• Una base de datos de depósito de reciente implementación, no conectada en red. Es utilizada como control de ingresos y egresos. No está siendo utilizada como control de stock crítico.
• Una base de datos de identificación de pacientes atendidos (sólo se incorporaron los pacientes y no la totalidad de la población, aun cuando luego de varios años de uso se acerca bastante a dicha magnitud).
• La misma es utilizada para el control de circulación de historias clínicas analógicas. Se registra la ubicación de las historias cuando éstas son llevadas a los consultorios, internación u otras áreas. No almacena más que el último evento, es decir no se puede conocer por ejemplo, cuales fueron los 5 o 10 últimos prestadores que la solicitaron.
• Es accedida por la base de datos de laboratorio para asignar así los resultados.
• Es utilizada para la asignación de turnos anticipados y para conocer los datos de pacientes de los que sólo se disponen su nombre y apellido.
• Una base de datos de Estadística, donde constan la cantidad de consultas e internaciones por servicio y Centros Periféricos de Salud.
• Una base de datos de Anatomía Patológica, donde se registran los pacientes, y los datos relacionados con el material a biopsiar así como sus resultados.
• Servicios como Maternidad y Pediatría registran sus propios datos haciéndolo según sus propias sistematizaciones. Dichos datos son de utilidad para esos servicios no siendo compartidos por otros.
• Una base de datos de facturaciones a Obras Sociales. La misma no escompleta ni tampoco es fiable. En análisis retrospectivos dicha base de datos no pudo ser utilizada por considerársela parcial y no fiable.


Comentarios sobre las bases de datos existentes:

La base de datos de depósito no es utilizada como control de stock con nivel crítico. Por ello, la Unidad Compras debe realizar las adquisiciones ante pedidos de suministros de prestadores que advierten que se han quedado sin insumos al solicitarlos a depósito.
No existe definición de nivel crítico por insumo. Tampoco existe control de utilización de equipamientos, ni previsión de salidas fuera de servicio temporarias o definitivas. Estos datos debieran estar registrados con sus indicadores de nivel crítico correspondiente.
La entrega de insumos desde depósito no está relacionada con una base de datos en cada sector donde son entregados los mismos. No existe posibilidad de correlacionar la cantidad entregada con la utilizada por prestación. Por ejemplo, no se pueden cruzar cantidad de pacientes por mes, con cantidad de insumos solicitados para establecer una tasa de uso.
Si se deseara establecer los costos operativos por cantidad de prestaciones en forma global, tendrían que recurrir a los recibos de entrega, que por su magnitud son de difícil análisis. Pero tampoco sería factible, por no existir además imputación por prestación.

Desde el punto de vista del prestador, cuando un médico desea consultar un análisis de un paciente, o una biopsia, debe llamar por teléfono (insumo de tiempo), pedir al personal de laboratorio que busque el resultado y se lo dicte por teléfono (insumo de tiempo + posibilidad de error humano al expresar los datos y/o al escucharlos).
Cuando un médico se dispone a atenter un paciente con turno, debería siempre contar con la historia clínica del mismo para poder repasar los datos antes de que el paciente ingrese. Al no contar en todas las ocasiones con la historia clínica, debe atender al paciente sin dicha información en tiempo oportuno.
Cuando un médico tiene una sospecha epidemiológica le resulta difícil comprobarla o llevar a cabo un estudio. Para ello debería recurrir a todas las historias clínicas, buscando por edades, sexos, las patologías y/o datos que necesite, tarea obviamente imposible.
Cuando un planificador tiene que hacer un diagnóstico de situación y simplemente solicita las planillas diarias de estadística, puede ocurrir que no las encuentre. En este caso, al intentar hacer un estudio de ocurrencia de patologías durante los últimos cuatro años tuvimos dificultades. Se solicitaron para el presente trabajo y para otros un muestreo de planillas diarias de estadística. La metodología era obtener ocho planillas por mes, incluyendo dos por semana seleccionando días diversos. Se truncó la búsqueda al sernos notificados que un año entero, el 1995, no se hallaba almacenado. Tampoco se hallaron meses de otros años.
Si hubiésemos deseado hacer un estudio de mayor complejidad, naturalmente que no hubiésemos podido hacerlo.


Así, se llegó a la conclusión de que antes de planificar, debíamos ponernos a solucionar esa enorme falla del sistema: la falta de registros, la carencia de una metodología para asegurar su almacenamiento y la falta de planificación para el ingreso de datos.


La demanda insatisfecha, la desorganización creciente de los Sistemas de Salud, así como la carencia parcial de registros y su dificultad para utilizarlos en tiempo y forma, se han convertido en un importante tema de debate en la actualidad. Lamentablemente no en la medida de lo deseado. El grado de convocatoria de esta discusión es bajo como para establecer una expectativa a corto plazo.

Cuando los médicos analizan historias voluminosas, es difícil que puedan llegar a leer los datos positivos en poco tiempo. Si bien se han instrumentado hojas de diagnósticos que pueden suplir dicha labor, no constituyen una solución a la hora de hacer análisis de datos de múltiples historias con miras a conclusiones epidemiológicas.
Actualmente no es factible utilizar los registros de las historias clínicas para fines Epidemiológicos sin tener que disponer de una gran cantidad de tiempo y esfuerzo para ello.
Con la finalidad de dar el puntapié inicial, en agosto de 1997 se elevó una propuesta al Sr. Ministro de Salud y Acción social. La misma consistía en un anteproyecto volcado en una sóla página (para invitar a su completa lectura), sobre el diagnóstico de situación y la propuesta de solución.
Luego de casi dos meses de consideraciones, me fué solicitado el proyecto completo, el cual fue girado rápidamente. Posterior a ello, el Sr. Subsecretario de Salud, unilateralmente, mediante Resolución designa una ‘Comisión Técnica Informática’ la cual con dos miembros por cada ciudad (Ushuaia y Río Grande) debería dar solución al problema existente.
Dado la altura del año, las licencias anuales reglamentarias y una extraordinaria ( decreto 89/97 = 30 días adicionales de licencia ), se prorrogó en los hechos su puesta en funcionamiento hasta febrero de 1998.
Ya en febrero/98, el Ingeniero Walter Díaz y el Dr. Francisco Leandro Loiácono comenzaron a elaborar la planificación y la estrategia a seguir. Actualmente se ha concebido un diseño, que será consensuado con la planta médica del Hospital de Ushuaia, para luego compatibilizarla con el Hospital de Río Grande.
Como propuesta de lo anterior, surge Historia Clínica Informática (HCI) como una herramienta posible, y con proyección a los fines Epidemiológicos y de Planificación en Salud.

Análisis extensivo, Ventajas comparativas del método:

 Los Profesionales de una Institución Hospitalaria tienen inconvenientes en la velocidad de acceso a los datos de sus clientes. La búsqueda de una Historia Clínica Analógica induce a demoras. Se debe tener presente que hay que disponer de un personal administrativo que solicite la historia, otro que la busque y otro que la transporte al consultorio. Esto puede abreviarse a una llamada telefónica del profesional y a un sólo administrativo que la busque y la traiga, en cuyo caso alguien debe atender el teléfono para una próxima requisitoria. En fin, se trata de una cadena con muchos eslabones. Como sabemos, cuantos más eslabones haya, más posibilidades de fallas o demoras pueden existir.
 La disponibilidad debe ser inmediata. Cuando un profesional debe consultar la Historia Clínica de un cliente, (o la cantidad de historias que desee en un momento dado), debe poder hacerlo sin demora en su obtención.
 En Instituciones de mediana y gran envergadura, cuando una Historia es llevada a un Profesional y posteriormente es precisada por otro, tiene un factor agregado de demora, ya que al concurrir a buscarla al Archivo General no se la encuentra. En dichos casos primero hay que confirmar que fue salió del Archivo para luego buscarla en el Consultorio donde estuvo siendo utilizada. Puede ser hallada allí o no, generando demora, desaliento del usuario y fundamentalmente visto desde lo sanitario: mal servicio hacia la comunidad.
 En los casos en que el cliente haya estado internado tampoco estará la Historia Clínica en el Archivo General. Habrá que buscarla en la Secretaría de Sala, otra demora en la disponibilidad de la misma. Además, por error, una Historia puede ser almacenada en un lugar equivocado del archivo y así perderse, por lo menos temporariamente, hasta ser encontrada luego de la búsqueda o bien, accidentalmente al buscar otra historia. Si bien son situaciones evitables, la realidad nos indica que existen.
 La comparación de datos sanitarios entre clientes es prácticamente incompatible con la búsqueda en el Archivo analógico. Es necesario tener mucho tiempo disponible, y en ocasiones la tarea es tan titánica que es imposible llevarla a cabo.
 Esta situación de disponibilidad es la que hizo que la Historia analógica fuese cuestionada.
 La historia analógica enlentece el funcionamiento del Sistema de Salud y no permite llevar a cabo cruces estadísticos entre los múltiples registros. Es aquí donde la informática alcanza su máxima substantividad.
 Las Historias Clínicas analógicas pueden ser sustraídas en forma total o bien parcialmente sus hojas, y hasta incluso pueden ser modificados algunos de sus datos. Además, pueden ser consultadas por cualquier persona que tenga acceso al área de archivo. La historia clínica informática sólo podrá ser leída por profesionales responsables de la atención, y con firma electrónica que certifique quién tuvo acceso.
 Las Historias Clínicas son documentos de extraordinaria importancia médica, sanitaria y Legal. Por seguridad sería importantísimo que no fuese posible su modificación. Si bien es difícil lograr dicho objetivo con cualquiera de las proposiciones actuales, es necesario intentarlo, o por lo menos apuntar a reducir y dificultar fuertemente las maniobras que tienden a producier modificaciones de sus datos.
 El advenimiento de la informática y de las bases de datos, permitió la posibilidad de informatizar la Historia Clínica de los clientes.
 Como todo cambio, generó resistencias. Por ello, se sugiere la instrumentación gradual. Es importante no pretender un cambio global sino escalonado.
 Es posible implementar la HCI. Su uso permitirá establecer cruces de datos entre historias con la velocidad propia de la computadora. Esto no es posible con las historias analógicas.
 Un Epidemiólogo, Estadista, Administrador o Profesional en Salud, puede determinar si en un período determinado de tiempo existió una determinada patología, su incidencia por grupo etario, sexo, si la población afectada tenía servicios cloacales, cuál era la composición de sus ingresos, cuál la composición de su núcleo familiar, si tenían antecedentes patológicos o no, y todo otro dato de interés en cuestión de muy pocos minutos y tal vez en segundos.
 Con dicho recurso, la base de una planificación sanitaria está servida a la espera de proponer soluciones.
 Esto implica poder disponer de la información en tiempo real, a medida que va sucediendo sin tener que comisionar personas a tal efecto, y sin tener que asignar tareas desagradables y tediosas al recurso humano que de otro modo puede destinarse a mejorar la atención al público.
 Es posible lograrlo con sólo sentarse frente al teclado y ‘solicitar’ lo que se desea obtener, sólo hay que saber cómo hacerlo y qué es lo que se pretende obtener.
 Resumiendo, la HCI soluciona problemas de disponibilidad y además permite un desarrollo estadístico epidemiológico de la información.
 Esto implica consecuencias, la inmediata es que el personal administrativo disponible tendrá tiempo para una mejor y más eficiente atención al público, ya que no soportará la pesada carga de manejar el ‘tráfico’ de historias clínicas.
 Permitirá a los profesionales de consultorios externos contar con la historia antes de que el cliente ingrese al consultorio, de modo que pueda informarse del cuadro clínico e iniciar la prestación con mayor eficiencia. Ésto es muy apreciado por los clientes, ya que es mal visto que el profesional no recuerde las consultas previas. Esto implica mejor atención al público a la par aque mejora los índices de satisfacción.
 Además, los profesionales pueden tener dudas sobre si el cuadro clínico que presenta el cliente a su vez está siendo padecido por muchas personas concomitantemente, pudiendo así anticiparse más pronta y precisamente a la posibilidad de una epidemia o de un incremento en el registro de casos.
Podrá hacer una búsqueda ágil y confirmar si lo que padece su cliente es una
enfermedad que también esté afectando a varios miembros de la comunidad.
También podrá comprobar si es una afección que provino de un turista o
visitante, y así con otras variables.
 Se despertará en el profesional el espíritu de investigación actualmente impedido por el difícil acceso a los datos registrados y la imposibilidad de su manejo. Esto redundará en un beneficio cuya proyección no podemos predecir al momento de diseñar el sistema.
 Los responsables de la Política Sanitaria y sus colaboradores, podrán mediante el uso de una terminal ‘resumir’ toda la evolución de la salud de la población en tiempo real, sin recurrir a laboriosos métodos de recolección de datos. Los mismos profesionales cubrirán mediante sus registros, parte de las funciones de los agentes sanitarios, permitiéndole a éstos últimos ocuparse más en profundidad de su labor.
 La tarea se torna multiplicadora: de personal administrativo, de más servicio a la población y de información estratégica.
 La Informática dejó de ser una herramienta para transformarse en un verdadero estructurador del Sistema. Lamentablemente y a pesar de la gran difusión de la misma, todavía no se usa correctamente aprovechando su potencial.
 No se encuentra un área informática en la gran mayoría de las instituciones, y cuando existe, la misma tiene un rango menor. El uso que se le dá es fragmentado. Cuando existe una red, la misma no ha sido fruto de una planificación sino de un voluntarismo de algunos precursores con un crecimiento anárquico.
 La informática está llamada a ser una de las áreas importantes de cualquier institución, colocándose a la par de las áreas sustantivas de la misma. Este tipo de desarrollo requiere de la asignación de jerarquía adecuada. Esa jerarquía implica un lugar definido en el organigrama de la Institución, dependiendo directamente de los cuadros gerenciales. Ya existen especializaciones en informática médico hospitalaria con residencias. El avance de la utilización de la informática en Salud recién está asomando.
 Debe tener lugar físico y personal propio, debe participar de las decisiones de managemet y enlazarse de la mejor manera con los actores sustantivos. Por desgracia, éste tipo de comentarios suele tomarse como una colección de palabras no dándosele el sentido que se debiera.
 La HCI se inserta dentro de un contexto informático generalmente preexistente en las Instituciones, como lo son
 a) Sistema de Turnos
 b) Sistema de Facturación
 c) Sistema Contable
 d) Sistema de Depósito
 e) Sistema de Estadística
 f) Sistema de prestadores intermedios (Laboratorio, Diagnóstico por Imágenes, Anatomía Patológica)
 g) Servicio Social
 h) Servicios Legales
 i) Salas, quirófanos, UTI, UCIN
 j) Esterilización
 k) Personal
 l) secretarías de consultorios
 m) Despacho
 n) otros


DESARROLLO:


1. Uno de los principales puntos de partida para desarrollar el proyecto es conocer la dimensión requerida para un correcto funcionamiento. Para ello se debe analizar cuál debe ser la cantidad de terminales al momento de su instrumentación y la proyección que tendrá en el tiempo de acuerdo con las características de crecimiento demográfico y incremento de la complejidad institucional. Estas previsiones incluirán el espacio físico por donde discurrirá la red y las anexiones futuras.
2. El segundo factor es el grado de aceptabilidad por parte de los usuarios.
3. El tercer factor es el grado de convencimiento de las bondades del sistema por parte de los responsables de Salud Pública a fines de financiar e implementar el proyecto adecuadamente.
4. El cuarto factor está relacionado con la modificación de la demanda de atención que un mejoramiento en el funcionamiento de la Puerta de entrada al Sistema genera éste tipo de instrumentos.
5. El quinto factor a tener en cuenta es que éste desarrollo informático debe ser considerado como una herramienta estratégica y por lo tanto factible de tener connotaciones alejadas a su objetivo primario. La más importante es que determina el cambio de mentalidad de todo el recurso humano y de allí en adelante, las consecuencias no pueden anticiparse.

Respecto del primer punto, se debe definir cuáles serán las áreas del Hospital a ser informatizadas, o cuáles lo serán hoy y cuales mañana. Se preveerá el crecimiento vegetativo que se espera tendrá la población en los próximos cinco años ya que ello podrá influirá en el crecimiento del Hospital y posiblemente (según la magnitud) también de la red.
Esto es importantísimo ya que el Sistema debe cubrir a todos los prestadores, no es posible que cubra a algunos y a otros no.
Hay una sóla excepción a ésto, cuando se instrumenta una etapa preliminar del proyecto la cual es altamente aconsejable para realizar una prueba a escala reducida.
Sobre éste punto es necesario insistir: se trata de un proyecto cuya implementación debe ser precedida de una prueba de campo a escala reducida.
Y esto no por su presunta falibilidad, sino porque el sistema se debe ajustar a la Institución y no la Institución al Sistema. Es altamente recomendable, que quienes diseñen el Sistema sean actores de la Institución, que conozcan no sólo su funcionamiento interno, sino también la cultura organizacional de la misma. Deberán conocer el personal, sus preferencias, sus tiempos, sus expectativas.
Cuando se trabaja con equipos profesionales con responsabilidades y riesgos, nunca se debe anteponer el sistema a los mismos. Se debe tener en cuenta que que el sistema generará cambios en los efectores, por ello, deberá por lo menos ser amigable.
Deben usarse plataformas que por su difusión sean rápidamente asimilables por los usuarios, en este aspecto lo más recomendable en nuestro medio es Windows, debido a que casi excluyentemente es la que resulta conocida por los potenciales usuarios.

Se deberán instaurar terminales en las siguientes áreas:

Consultorios: una terminal por consultorio. Además se deberán incluir terminales para cada efector que produzca diagnósticos, resultados y tratamientos factibles de ser registrados. La cantidad en éstos casos deberá ser suficiente como para evitar que el acceso a las mismas sea dificultoso. En ésto es necesario ser claro: el prestador no debe tener ninguna dificultad en el acceso a las terminales para poder así 1) volcar datos y 2) procesar Información.

Office de Internación (*): se recomienda una por cada Office.

Dirección Médica: una terminal.

Centros Periféricos: una por cada consultorio de Primer Nivel de Atención.

Quirófano (*): una terminal por cada tres quirófanos. Servirá a los propósitos de relevar la estadística de cirugías, consumo de insumos y destino de los mismos ya sea por Servicio o por módulo de prestación.

Anatomía Patológica (*): una terminal por cada dos Patólogos

Laboratorio: Una terminal por cada dos bioquímicos.

Diagnóstico por Imágenes (*): una terminal por cada radiólogo que produzca informes.

Fiscalización Sanitaria (*): cuya consulta estará fundamentada por la existencia de un campo donde se consignen los días de licencia otorgados.

Escuela de Salud Pública (*): sólo para consulta estadística (datos y no identidades de clientes ) pertinente a los fines docentes.

Ministerio de Salud y Acción Social (*): sólo para consulta estadística (datos y no identidades de clientes )

(*) áreas no contempladas en la variante A.P.S. Si la red estará destinada por decisión de las autoridades sólo a la A.P.S. se recomienda no incluir dichas áreas, salvo mejor opinión en contrario.

La proyección de incremento en los cinco años futuros a su instalación, estará supeditada a cálculos que surgirán de los análisis pertinentes de la Administradora de SILOS.

Dado que la velocidad del Sistema Informático es crítica para que resulte de verdadera aplicación en lo apuntado con anterioridad, es menester plantearse las siguientes dos opciones:

1) Uso exclusivo para la APS (Atención Primaria de la Salud) sumada a Laboratorio
2) Uso generalizado abarcando todas las áreas hospitalarias.

La comunicación entre Centros Periféricos de Salud y el Hospital no precisa ser en tiempo real, sí mediante actualizaciones cuya periodicidad se sugiere analizar en base a la producción de eventos por parte de los sectores de Diagnóstico y Tratamiento, Internación y Cirugía. La actualización será mandatoria cada vez que una terminal acceda a un registro, antes de utilizarlo. De lo contrario, la actualización de todas las terminales ocurrirá al final del día, evitando así saturaciones de requerimiento en momentos inoportunos.
El segundo punto se refiere al grado de aceptabilidad de los usuarios, es tal vez el punto más crítico, ya que contra lo previsible, en experiencias previas se ha constatado que los profesionales presentan resistencias al uso de la HCI. Incluso los más entusiastas del método presentan un determinado grado de resistencia.
Esto se puede superar con la participación de los mismos en el diseño, lo cual además constituye un elemento indispensable a la hora de implementación del sistema.
La participación debe permitir incorporar aportes que son de indudable utilidad para mejorar el rendimiento del Sistema. Esto vá en contra del uso de programas cerrados.
El tercer punto se refiere al convencimiento de las autoridades para implementar el sistema. Se aconseja no implementarlo si el convencimiento no es el adecuado. Ello haría fracasar no sólo el intento sino que además perjudicaría la imagen del método para futuros aplicadores en mejores condiciones.
Sobre la circulación y almacenamiento de la información, se deben tomar una decisión y elegir entre:

1) Un Main-frame o sea una central única de consulta y procesamiento para todos los usuarios;

2) Sistemas distribuídos interrelacionados: esto significa terminales inteligentes con capacidad de almacemiento propio mediante bases de datos que envían actualizaciones a una Central la cual retransmite a la red. La actualización tendrá como elemento de prioridad la comparación según la fecha y hora de actualización para evitar anacronismos.

3) Ídem a (2), pero con la incorporación de una terminal de acceso limitado al/los responsables del Hospital (Director, Consejo de Administración), cuyo update esté condicionado para evitar actos de corrupción de archivos producto de intencionalidades o de elementos fortuitos. Sería una subvariante de la opción dos.

Las desventajas del mainframe es que los procesos estadísticos cuando sean requeridos y se espera fervientemente que así ocurra, consumen demasiado tiempo y recursos, privando al Sistema temporariamente de la ventaja de su agilidad.
Naturalmente que también dificultará las consultas compartidas de dos o más usuarios sobre los registros.
En un sistema distribuído interrelacionado con bases de datos en cada terminal, se agilizarán los procesos estadísticos en forma absoluta, ya que cada análisis operará sobre el disco rígido de dicha terminal.
También ante la hipotética pero real pérdida de datos en el mainframe, la información estará disponible en cada una de las terminales, permitiendo solucionar el inconveniente rápidamente con una transferencia de datos. También desde lo legal, es más dificultoso modificar todas las terminales, que como en el caso del Mainframe modificar una de ellas.
En contra de instalar bases en cada máquina podría citarse el espacio de disco que debe disponer cada máquina y por ende el costo por terminal. Sin embargo, el mecanismo de Resumen de Historia Clínica codificada, no precisa más de 6000 bytes por registro. En una población de 50.000 habitantes significa 300.000.000 bytes.
Hoy en día un disco duro de 2 GB es de bajo costo y permite almacenar la base de datos y el Sistema en un bajo porcentaje de su capacidad.
Ante una caída del mainframe, cae todo el sistema, en cambio, si cae una sóla de las terminales, sólo se perjudica esa área de servicio.
Si recordamos que el movimiento de consultorio estará regido por la HCI, es importantísimo evitar las caídas globales.

Respecto del costo, no hay una diferencia substancial a la hora de analizar las ventajas comparativas.
La actualización se llevará a cabo mediante envío de datos por red desde cada terminal hasta una Central que físicamente se aconseja ubicarla en un lugar de acceso restringido del nosocomio. Ésta terminal producirá las actualizaciones de las demás en tiempo real.


CARACTERÍSTICAS DEL SOFTWARE

Se ha planteado un resumen de Historia Clínica porque en una primera etapa que estará comprendida entre los primeros 3 a 5 años, no se aconseja el uso de una HCI completa. El cambio sería muy agudo y podría provocar el rechazo. Además no ofrecería una ventaja comparativa substancialmente mayor.
El resumen de HCI permitirá conocer todos los datos identificatorios del cliente (Nombres, Apellidos, procedencia, fecha de nacimiento, edad actualizada por sistema, domicilio, teléfono/s), cobertura de salud, familiar relacionado, estado civil, hijos, tipo de vivienda, servicios de la vivienda, antecedentes regionales según pueblo/ciudad de procedencia y todo otro dato que se desee agregar con motivo de mejorar la información epidemiológica.
Además permitirá conocer todos los Antecedentes Hereditarios, Personales entre ellos los quirúrgicos y obstétricos, todos los Diagnósticos, y también las consultas recientemente realizadas (se sugiere almacenar las últimas veinte -20- ).
Los diagnósticos serán almacenados codificados a los fines de: 1) reducir el espacio en el registro y 2) favorecer la unificación de nomenclatura para permitir los procesos estadísticos.
A tal fin se puede contar con la clasificación de enfermedades de la Organización Mundial de la Salud (O.M.S), ICD-10 CM.
El usuario seleccionará de una lista ordenada alfabéticamente un diagnóstico al cual el software internamente le asignará un código precargado por los usuarios. Cuando el usuario desee conocer los diagnósticos consignados al cliente, los podrá obtener mediante una opción del menú.
El software deberá recoger del archivo de datos un código (o varios) y lo/s decodificará presentando al usuario los diagnósticos por su expresión nominal. En el texto de las consultas en cambio, sólo se apicarán codificaciones que compriman el mismo. A pesar de ello, existirá un límite para la escritura de textos en consultas.
Se contempla que cada intervención (lectura o escritura) llevada a cabo por el usuario (excepto la estadística) sea asentada en el registro correspodiente a cada cliente, previéndose hasta cien eventos con su fecha, hora y nombre del usuario.
Todos los elementos mencionados son factibles de almacenarse en 6000 bytes por registro (cada registro equivale al resumen de HCI por cada cliente).
Con 6000 bytes se pueden almacenar hasta 20 factores de riesgo, 25 antecedentes hereditarios, 50 antecedentes personales, 20 diagnósticos activos y hasta 20 consultas de 400 bytes cada una (que comprimidas por sistema representan 200 bytes a ser almacenados). Estas cifras por su amplitud brindan amplias posibilidades de no ser excedidas.





Campos sugeridos para la constitución de un registro:

• Nombre: 20 bytes
• Apellidos: 25 bytes
• Fecha de nacimiento: 6 bytes (se guarda sin separadores de campo)
• sexo : 1 byte (codificado)
• tipo de documento: 1 byte (codificado)
• nro Documento : 10 bytes
• Domicilio del paciente: 20 bytes
• Localidad donde vive el paciente: 1 byte (codificado)
• Teléfono del paciente o persona próxima: 12 bytes
• ObraSocial : 2 bytes (codificado)
• NroAfiliado :14 bytes
• Carencias Obra Social : 1 byte (codificado)
• Nombre y Apellido de Familiar: 25 bytes
• Domicilio Familiar: 20 bytes
• Teléfono Fliar :12 bytes
• Centro de Salud Periférico: 1 byte
• Médico de Familia : 1 byte (codificado)
• Ciudad Natal :15 bytes
• País Natal: 2 bytes (codificado)
• Provincia Natal : 2 bytes (codificado)
• EstadoCivil : 1 byte (codificado)
• Total Hijos: 2 bytes
• Hijos 1er. Union : 2 bytes
• Vivienda: 1 byte (codificado)
• Energía eléctrica: 1 byte (codificado)
• Gas : 1 byte (codificado)
• Agua : 1 byte (codificado)
• Cloacas: 1 byte (codificado)
• Calefaccion: 1 byte (codificado)
• Actividad Laboral: 1 byte (codificado)
• Factores de riesgo: 20 bytes (codificado:cada byte representa un factor)
• Antecedentes Hereditarios: 225 bytes (codificado: admite 25 Antecedentes de 9 bytes cada uno según composición a saber:)
• Bytes 1 al 3 = código OMS
• byte 4= firma electrónica (codificado)
• byte 5=día (codificado)
• byte 6=mes (codificado)
• byte 7=año (codificado)
• byte 8=hora (codificado)
• byte 9=minutos (codificado)
• Antecedentes Personales: 450 bytes (codificado:admite 50 Antecedentes de 9 bytes cada uno según composición a saber:)
• Bytes 1 al 3 = código OMS
• byte 4= firma electrónica (codificado)
• byte 5=día (codificado)
• byte 6=mes (codificado)
• byte 7= año (codificado)
• byte 8=hora (codificado)
• byte 9=minutos (codificado)
• Diagnósticos Activos: 180 bytes (codificado: admite 20 Diagnósticos Activos de 9 bytes cada uno según composición a saber:)
• Bytes 1 al 3 = código OMS
• byte 4= firma electrónica (codificado)
• byte 5=día (codificado)
• byte 6=mes (codificado)
• byte 7= año (codificado)
• byte 8=hora (codificado)
• byte 9=minutos (codificado)
• Consultas: 4000 bytes (comprimidos con código autogenerado, permitiendo 400 bytes por consulta con una razón de compresión no menor a 2:1 lo que equivale a 200 bytes efectivos a almacenar, lo que presupone en 20 consultas 4000 bytes totales)
• Firma : 600 bytes (codificados como firma-fecha-hora: registra 100 firmas de 6 bytes cada una, según el siguiente detalle: )
• byte 1=username (codificado)
• byte 2=dd (codificado)
• byte 3=mm (codificado)
• byte 4=yy (codificado)
• byte 5=hora (codificado)
• byte 6=minutos (codificado)

Lo Anterior puede resumirse sintéticamente del siguiente modo:

1- Datos Identificatorios: 203 bytes (algunos de ellos codificados)
2- Factores de Riesgo: 20 bytes (hasta 20 factores de riesgo de 1 byte c/u)
3- Antec. Hereditarios: 225 bytes (hasta 25 antecentes hereditarios de 9 bytes c/u)
4- Antec. Personales : 450 bytes (hasta 50 antec. Personales de 9 bytes c/u)
5- Diagn. Activos: 180 bytes (hasta 20 diagnósticos activos de 9 bytes c/u)
6- Consultas: 4000 bytes (hasta 20 consultas de 400 (2:1=200 bytes c/u)
7- Firmas: 600 bytes (hasta 100 firmas de 6 bytes c/u)

Total de bytes 5678 bytes por registro (por paciente)

Cabe aclarar que cada Antecedente Hereditario, Personal, diagnóstico o consulta que se registre, lleva implícita la firma electrónica de quién la efectuó, además de la fecha y hora. Esto significa que se identifica al autor de cada dato consignado.
Pero además, se tiene un registro de firmas (punto 7), en el cual se registran los últimos 100 profesionales que accedieron a una historia clínica, con fecha y hora.

La diferencia crítica entre un resumen y una HCI completa es que no se grabarán todas las consultas que genere el cliente en el archivo de datos informático (sí sus diagnósticos y tratamientos). Tampoco se volcarán en ella las hojas de enfermería, y los resultados de laboratorio y otros estudios. Dichos resultados podrán ser accedidos desde las bases de datos de los sectores correspondientes. Sólo se prevee registrar las últimas 20 consultas realizadas.
Desde el punto de vista legal, el registro de todas las consultas es de sumo interés, por ello, luego de cada consulta y mediante impresoras centralizadas en un lugar físico (se sugiere el sector Archivo del nosocomio), se imprimirán hojas con el texto de la consulta que el profesional escriba en la terminal.
Posteriormente cada profesional las firmará al final del día y el personal administrativo las archivará en la historia clínica analógica. Además cada hoja impresa llevará una firma electrónica autogenerada que contemplará el día la hora y el usuario.
Esto implica que la historia clínica analógica no desaparecerá, sino que pasará a ser información de resguardo. En cambio se usará como fuente de datos cotidiana, la Historia Clínica Informática.
Un beneficio adicional es que la magnitud del gasto de papel con la historia analógica es mucho mayor que con la historia informática debido esencialmente a que una impresora abarca mayor cantidad de palabras por renglón que la mayoría de las escrituras de los profesionales. Además el grado de comprensión de la lectura de textos impresos es de un ciento por ciento.
Finalmente el ordenamiento será estrictamente único, ya que la HCI no admite ingreso anárquico de datos. En cambio, las historias analógicas suelen tener una elevada tendencia a la anarquía organizativa.
Cada usuario tendrá asignado un ‘nombre de usuario’ y una clave de acceso. Además existirán superusuarios que necesariamente podrá acceder al sistema a fines de solucionar los inconvenientes que surgieran.
Cada vez que un usuario acceda al sistema, quedará grabado el día, la hora y su nombre en la historia identificándolo. El sistema propuesto registra hasta cien eventos, ulteriormente borra el más antigüo permitiendo al más reciente ingresar en la lista.

Se sugieren cuatro (4) categorías de usuarios:
1- usuarios con acceso limitado a los datos identificatorios del cliente. Reservado para personal administrativo que recepte al usuario. Deben estar debidamente capacitados para agregar o modificar datos identificatorios de los clientes. Por ejemplo el cambio de teléfono o de dirección, o bien cambio de familiar o amigo a quién recurrir en caso de necesidad, etc.
2- usuarios con acceso limitado a los campos correspondientes a los resultados. Está apuntado a los usuarios que deben cargar en los registros datos de estudios de los clientes (laboratorio, diagnóstico por imágenes, anatomía patológica, citología exfoliativa, etc.)
3- usuarios con acceso al módulo de passwords (pases). Este es el caso de quienes manejan el Sistema Informático y deben poder modificar los pases y usuarios. Para una mayor seguridad, se puede habilitar el ingreso al corazón del sistema mediante dos pases secuenciales, es decir, que sean necesarias dos personas con sus pases correspondientes para poder acceder al sistema. Esta actividad también debe ser registrable. A fines de evitar inconvenientes, se deberá autorizar a por lo menos 6 (seis personas), para que conjuntamente con el diseñador del sistema puedan acceder a áreas reservadas del mismo. Si bien se sugieren 6 personas, en el momento de acceder al mismo sólo harán falta dos pases: a) el del diseñador del sistema y b) cualquiera de las 6 personas seleccionadas. No podrá ocurrir que dos personas de las 6 seleccionadas puedan acceder al sistema, sino que necesariamente debe participar el diseñador. Se recomienda fuertemente que los pases ( y sus modificaciones) de los 7 involucrados en éste punto sean consignados por escrito en sobres separados y reunidos en un sobre mayor a custodia de la autoridad de Salud.
4- Usuarios con acceso a los datos identificatorios y a los datos médicos del cliente pero sin acceso a modificaciones de pases (ver punto 3). Éste es el caso del profesional que atiende al cliente. Se puede incorporar la variante de habilitación por caja, que consiste en habilitar al cliente que pasa por la Caja del hospital y cumple con el trámite correspondiente. De ese modo se habilita el acceso al Resumen de HCI de dicho cliente para que sea accedido por determinado profesional, esto es una habilitación ligada al prestador. Esto permite proteger los datos de profesionales no involucrados con el cliente y que accidentalmente o no pueden ser modificados por otro profesional. A fines de mayor seguridad se puede incorporar a cada dato consignado en la HCI un campo que contenga la identificación del profesional actuante.

En cambio la actividad Estadística y de cruce de datos estará libre de limitaciones ya que no modifica datos (sólo lee) y no conlleva identificación de los registros consultados.

PASOS A SEGUIR PARA LA IMPLEMENTACIÓN:

Se sugiere a fines de sortear inconvenientes el siguiente orden secuencial:

1) Toma de decisión política, que dado la repercusión del sistema a aplicar se aconseja fuertemente el conocimiento del Nivel Superior (Gobernador).
2) Discusión y elaboración de contratos de Locación de Obra y Servicios, con los objetivos y metas a cumplir y de los montos que económicamente surjan.
3) Determinar la cantidad de población y su crecimiento vegetativo.
4) Determinar las áreas y cantidad de terminales por área de servicio. Debe analizarse la proyección a futuro.
5) Determinar si se instrumentará una red para la Atención Primaria de la Salud (con conexión a Laboratorio) y otra para el resto de los subsistemas o si se instrumentará una opción única.
6) Determinar el tipo de opción de hardware: a) Mainframe b) Bases distribuídas interrelacionadas (sugerida), según lo cual corresponderá la elección de terminales;
7) Elaborar listado del equipamiento necesario y licitarlo;
8) Determinar los referentes por hospital para asumir el rol de multiplicadores ante los restantes efectores. Además de los referentes deberá designarse un conductor que evite la dispersión de esfuerzos y mantenga la visión de conjunto además de preservar el espíritu del Proyecto. El proyecto deberá contar con respaldo político adecuado y deberá ser instrumentado desde una Resolución.
9) La población deberá estar al tanto del Sistema en detalle y se realizarán por los medios que sea menester una campaña de información y concientización de que se está ante un cambio de Sistema. Sería oportuno implentarlo conjuntamente con una política de SILOS. Esta campaña informativa no es un dato menor, sino que mas bien es un punto de gran importancia. El cambio no deberá ser traumático para los profesionales, sino que éstos a su vez transmitirán sus emociones negativas a los clientes. Por ello es importantísimo que los clientes conozcan el método y ayuden a la contención de los profesionales en la etapa inicial;
10) Elaborar los campos por registro para lo cual se adjuntará un modelo a modo de guía, factible de ser personalizado por la Institución;
11) Seleccionar la plataforma (sugerencia: Windows 32 bits) que permita además un adecuado manejo de imágenes, (ejm.: imágenes endoscópicas, radiológicas, fotos, ecocardiográficas, TAC,RNM, angiografías, y otras). Naturalmente que los 6000 bytes por registro no preveen co