SGHM, Sistemas médicos, El soberano y los esclavitos

Este artículo es una mezcla entre queja formal, documento informativo, petición de ayuda y hasta una forma de catársis con respecto al gran malestar que tengo sobre algunos procesos y “modalidades” de migración y de la comunidad del software libre en Venezuela.

Preámbulo: Sobre SGHM

SGHM fueron las siglas escogidas (casi que al azar) para indicar “Sistema de Gestión de Historias Médicas”; el SGHM se dispone a ser:

“Una aplicación sencilla, escalable, n-capa, múlti-servicios todas las necesidades del Sistema de Salud Venezolano (incluyendo los Centros Médicos Diagnósticos de Alta Tecnología), se ha tomado la decisión de modelar (y posteriormente implementar) una solución ntegrada de desarrollo que contempla entre otras cosas:
1. Gestión de historias clínicas distribuidas y escalables
2. Administración de los procesos médicos, ambulatorios y administrativos en un sistema abierto de flujo de trabajo
3. La utilización de una gran variedad de estándares internacionales de desarrollo de aplicaciones médicas
4. Implementación de una plataforma escalable y ampliamente distribuible
5. Gestión de todos los procedimientos médicos y administrativos (gestión clínica-hospitalaria)
6. Banco común de datos de personas y pacientes (permite por su estructura y jerarquía, realizar importantes manejos estadísticos así como minería de datos)
7. Llevar los requerimientos de hospitalización, servicios, pacientes de una manera centralizada o distribuida
8. Establecer estandares comunes de desarrollo para toda la plataforma de salud pública
9. Mejorar la seguridad de los sistemas administrativos-médicos actuales al implantar una plataforma de seguridad única y centralizable”

Un vinculo con un documento descriptivo de la idea aqui: SGHM y CMDAT

SGHM no ha recibido hasta los momentos ningún apoyo por parte de algún ente interesado; ya veremos por qué …

Pero el desarrollo de ideas y aplicaciones como esta se estrellan contra una gran cantidad de obstaculos, vamos a enumerarlos uno a uno.

Obstaculo 1: Tecnología

Existiendo alternativas (openEHR) y protocolos ya existentes (HL7), normas ISO y demás; es una apuesta innecesaria no utilizar estándares existentes (como XDS, un tipo de XML::OpenDocument ideal para el intercambio de información médica) y la construcción de aplicaciones siguiendo ideas y normas como IHE (Integrating Healthcare Enterprise); la gran mayoría de las personas aun apuesta por esquemas privativos; formas de trabajo obsoletas (plataformas cliente-servidor no escalables, ausencia de modelo SOA, o uso de una API no común y cerrada); un ejemplo clásico ocurre en ¿Por qué hacer un esquema propio de clasificación de enfermedades si ya existe ICD?, ¿Generar historias en PDF?, ¿Por qué si OASIS posee años de experiencia en el modelaje de estándares abiertos de formatos documentales, incluyendo uno para formatos médicos?.

La cuestión con la tecnología se estrella contra una segunda pared; la ausencia de personal realmente capacitado para llevar a cabo una propuesta de este tipo; en Venezuela, existe la costumbre altamente extendida de mentir en el curriculum; esta mentira se extiende a las capacidades de las empresas; muchas ofrecen una experiencia “solo igualable a la de Dios” en ambientes médicos, de gestión documental o de desarrollo de aplicaciones en SL y en algunas, solo veremos que tienen una demo en Visual Fox Pro.

El hecho de tener un sistema heterogéneo, de n-capas, con un backend en LDAP o PostgreSQL, choca con la ausencia de personas capacitadas no solo para entender el modelo de datos; sino que además, entiendan las herramientas donde se sentarán las aplicaciones (¿Cuantas universidades actualmente están enseñando postgreSQL o están enseñando normas LDAP v.3?); con lo cual, se hace imperioso que el sistema sea abierto, colaborativo, para obtener la mayor participación de la gente dispuesta; sin importar sin son venezolanos o neo-zelandeses.

Pero ahi viene la tercera pared y el obstaculo número 2.

Obstaculo 2: El esquema tradicional de “los esclavitos” versus “Desarrollo Colaborativo”.

Por lo general; es de común arraigo en Venezuela que las empresas desarrollan software y el estado les compra; en este caso es una simple transacción financiera capitalista; donde una empresa vende un software; este mal ejemplo ha sido “migrado” a la filosofía del software libre y en vez de crear grandes proyectos colaborativos; donde dos o más empresas se unan para colaborar con esta aplicación (OpenOffice: Proyecto Oasis; Ubuntu: Canonical; Bind-DNS-DHCP: ISC; etc) en Venezuela se sigue el esquema de reducir la migración a Software Libre a una simple transacción comercial donde “la empresa crea, el estado compra” o donde “el estado contrata y recibe un software).

El problema oficial de este esquema es que una sola empresa no tendrá el recurso para contratar a: expertos en modelado de aplicaciones y arquitectos, programadores con amplios conocimientos del lenguaje, especialistas de lógica del negocio, etc; como siempre digo en mis charlas “ninguna empresa venezolana que esté haciendo una aplicación en python podrá contratar de 8 a 12 y de 2 a 6 a Güido Van Rossum (creador de Python); pero podrá contar con su experiencia si libera el código y a Güido le gusta la aplicación”.

El término “esclavitos” deviene de la costumbre ancestral de que una aplicación debe ser desarrollada por gente de la misma empresa; sin intervención ni injerencia de entes externos; por ende, terminas contratando a cientos de chamos (pasantes, tesistas, perro-calienteros, quincalleros tecnológicos, etc) bajo el esquema de “sean inteligentes de 8 a 12 y de 2 a 6, lunes a viernes” y “les pondré computadoras, cigarros, internet y coca-cola”; sin embargo, en el área de SL todos sabemos que esto no es así (el 80% del código fuente del kernel Linux fue desarrollado en horas no laborales por técnicos de empresas como HP, IBM o Sun; el stack para webcams del kernel linux fue desarrollado por un matemático y físico del MIT luego que se jubiló y el profiling de los elevators del kernel fue optimizado por un anestesiologo en sus ratos libres) y este esquema lleva a un fracaso terrible; ya que además de coartar la libertad de colaborar a cualquier hora; nunca en tu staff de “esclavitos” tendrán la experiencia de años de desarrollo en tecnologías libres que podría tener cualquier miembro de la comunidad de SL y que quisiera participar colaborativamente en el proyecto.

¿Desde cuando estoy pidiendo yo tener acceso al código fuente de la aplicación de CADIVI para mejorar los errores de validación que tienen a nivel de la lógica del dominio? …

Obstaculo 3: La empresa capitalista y el esquema colaborativo

El tercer punto importante en esta cadena es que al tener una única empresa mamá de todos los pollitos y custodia del gallinero; nos encontramos realmente con una imposibilidad técnica y política de generar un desarrollo colaborativo; en vez de usar canales verdaderamente regulares del Software Libre (CENDITEL, RINDE, SourceForge) la tendencia es mayoritariamente a crear un entorno capitalista donde una empresa vende y un estado compra; nada de participación de la comunidad. ¿Alguien tiene acceso a la API del SENIAT o al repositorio del CNE? …

Una de las excusas más nombradas por este aspecto es tener a “alguien que me dé soporte” (más bien: “Alguien a quien echarle la culpa”); sin embargo, ya muchos usan OpenOffice y como he dicho, una cosa muy distinta es quien lleva el proyecto (Sun-Fundación Oasis) y otra es quien sabe OpenOffice y lo instala en tu oficina (cualquier empresa o cooperativa); mezclar ambos conceptos (quien te instala y da soporte es quien te hace la aplicación) es volver al viejo esquema de comprar licencias Microsoft.

Para los funcionarios y líderes de instituciones que “desconocen” la forma como se “debería” gestionar un proyecto de Software Libre; aquí va un flujo de trabajo:

  1. Se postula una prueba de concepto; basado en investigaciones dentro de la institución, sobre requerimientos y necesidades en materia de SL
  2. Se procede a la solicitud de empresas (y/o cooperativas) que puedan “facilitar” una plataforma de desarrollo colaborativo (repositorio, bugtracker, wiki, página de documentación del proyecto, página oficial del proyecto, etc) y una plataforma de pruebas (banco de pruebas) completamente confiable
  3. Se procede a hacer público el proyecto, a través de meRINDE y/o CENDITEL y se convoca a empresas a participar.
  4. Se nombra un líder oficial del proyecto; siendo la(s) empresa(s) las que mantendrán el desarrollo abierto y funcional.
  5. Se obtiene a través de LOCTI apoyo a aquellas empresas que presten horas/hombre de desarrollo colaborativo para la aplicación
  6. Se convoca a otros entes gubernamentales que se beneficiarán de la herramienta; a ayudar a pequeñas cooperativas y empresas a dedicar recursos al apoyo de este proyecto.
  7. Cada cierto tiempo las empresas líderes liberarán versiones “estables” del código para el uso por los entes participantes.
  8. Otros grupos organizados (e incluso la comunidad en general) podrá contribuir con parches, documentación, Wiki, traducción a otros dialectos, etc.

Este esquema no se cumple aun en NINGUNA aplicación funcionando actualmente en Venezuela; y eso nos lleva al siguiente obstaculo.

Obstaculo 4: Implantación de lo inestable

La gran mayoría del desarrollo de software (privado o abierto) en Venezuela; salvo ciertas excepciones, pasa directamente de su desarrollo a fase de implantación sin pruebas previas; siendo corregidos sus errores con data en vivo (¿cuantos fallos de aplicación fueron corregidos en la página del SENIAT cuando la gente se quejaba de su operatividad?); constituyendo esto el gran enemigo del software libre como lo conocemos.

Una cosa importante que aclarar es que por lo general todo software abierto se le considera en “beta perpetua”; porque siempre se le están agregando nuevas funcionalidades; eso no significa que como proyecto, todo código agregado debe ser “puesto en producción” sin unas pruebas previas al mismo y sin realmente estar completamente seguro que “en todas las plataformas, combinaciones, arquitecturas y clientes” el código va a funcionar como se esperaba.

El ciclo que por lo general se debería seguir es el siguiente:

  1. Se declara una “alpha” privada, en un portal vinculado al servidor de desarrollo, donde la gente puede probar la aplicación y recomendar mejoras o reportar bugs (esta alpha debe tener vínculos a los sistemas de bugtracking, tickets de soporte y al wiki del proyecto).
  2. Se declara una “beta pública” sobre la que se agregan pocos cambios y se van resolviendo los bugs de la alpha; se extiende el proceso de pruebas al mayor número de personas posible en la mayor cantidad de plataformas posibles
  3. Se declara una “versión estable” a la que solo se le corregirán los bugs que se vayan encontrando en el código
  4. Toda nueva solicitud de función, será agregado a la próxima liberación de una “alpha pública”; volviendo a comenzar el ciclo.

Dicho ciclo no se cumple; ya que en muchisimos casos ni siquiera se tiene acceso a un sistema de reporte de fallos para que las personas encargadas del desarrollo de la aplicación sepan “qué está fallando” y cuando lo deben corregir.

Otro de los grandes males que causa la implantación de lo inestable es la mala fama que muchas aplicaciones “hechas con Software libre” han sido mal diseñadas y le aportan mala fama al movimiento (recuerdo una aplicación hecha en visual basic, con un back-end en mySQL; los programadores hacian las consultas optimistas, con bloqueo de tabla y registros del lado del cliente; pero el que la aplicación fuera lenta era culpa de la “base de datos libre” y no del mal diseño de la aplicación VB); ¿Es culpa del estándar ECMA que CADIVI valide mi presencia en el portal usando un javascript desactivable? … no, es como le digo a todo el mundo, usando el argot OSI, ¡es problema de Capa 8!

Obstaculo 5: El FUD de las empresas de desarrollo

Muchas empresas (incluso en este proceso, de ayudar al CNE, MINSalud, ONIDEX) han llegado con extensa publicidad sobre sus grandes capacidades en SL; algunas publicitan sus productos como “software libre” pero solo le entregan el código a quien lo adquiere y no realiza ni transferencia tecnológica ni mucho menos le permite distribuir los cambios realizados al software; coartandose una o a veces todas las libertades del software libre.

Las empresas tienen a llenar no solo de publicidad de “dudosa validez” acerca de su experiencia; sino que además, llenan de FUD a la comunidad del SL y no le permiten a ésta participar del desarrollo, validación, ampliación o colaboración; convirtiendo a la comunidad de software libre más que en un aliado, en un enemigo.

Obstaculo 6: Cumplimiento de las libertades

Entiendase por las libertades del software libre; a todas aquellas acciones que le permitan a todos disfrutar de los beneficios y participar en el crecimiento y uso de una aplicación; una aplicación no puede declararse “libre” cuando no permite modificaciones en el código; cuando no permite “forks” o cuando no hace pública una API para realizar extensiones o mejoras.

El simple hecho de no cumplir las 4 libertades del software libre; debería descartar a cualquier desarrollo (venezolano o no) de ser “considerado” Software Libre. El decreto 3390 ha causado más un mal que un beneficio; al permitirle a las empresas captar clientes potenciales usando “desinformación” publicitandose como “héroes del software libre” aun cuando NADIE ha visto una línea de código de esas empresas.

Obstaculo 7: Paquete versus tecnología

De último, pero no menos importante se encuentra en el modo como se ha “orientado” la migración en Venezuela; por lo general históricamente el venezolano se ha acostumbrado en el área informática a ser consumista y a aprender “paquetes” y no “tecnologías” (ejemplo; en vez de ANSI C, aprendes Borland C, en vez de ANSI SQL, aprendes Oracle u MS SQL Server, en vez de aprender Basic, Visual Basic, en vez de (x)HTML aprendes Dreamweaver y en vez de aprender Documentación y ofimática aprendes Microsoft Office); por lo que erroneamente se ha enfocado a la migración de la misma manera; el reemplazo de un paquete por otro; en este caso, muchos ministerios (incluyendo el de salud) orientan al sistema de historias médicas no como un sistema abierto, interoperable, completamente GPL, sino en un “paquete” creado por una única empresa y como reemplazo de algún único paquete anterior (o en estos casos, un paquete que se implanta usando un modelo privativo de desarrollo en donde no habia nada).

El problema de esto es que no estamos fomentando la existencia de estándares, uso de tecnologías existentes ni tenemos la forma de formar especialistas en el área médica; volveremos a formar “expertos en paquetes”; pero esta vez, paquetes GPL.

El hecho de que pueda argumentar que un modelo “arbóreo” (tal vez LDAP) es más idóneo para organizar datos de personas y sus interrelaciones que una BD relacional (mySQL, postgreSQL) me da pie para pensar que puedo hacer un fork de una aplicación de historias médicas aplicando otra metodología y otra tecnología para mejorar su organización o tal vez su desempeño; pero, ¿como puedo crear un fork de una aplicación o como puedo participar en su mejoramiento tecnológico de algo a lo que no tengo acceso?.

El peor de los casos es cuando el paqueterismo crea “nichos”; donde el alto acomplamiento de los componentes que conforman el sistema hace virtualmente imposible que; por ejemplo, el sistema de CADIVI viva sin Oracle o el del CNE sin postgreSQL; tambien imposibilita la creación de sistemas heterogéneos.

Un ejemplo de un sistema heterogeneo podría ser combinar las capacidades de openLDAP y postgreSQL en una misma aplicación; más toda una infraestructura de comunicación basada; por ejemplo, en XML-RPC, permitiendole a aplicaciones de terceros ser “consumidores” de mi información, y no obligar a todo el mundo a llegarle a mi aplicación via “una página web hecha exclusivamente para Internet Explorer” como pasa con algunos proyectos.

Conclusiones

No podemos seguir otorgandole nuestras aplicaciones “vertebrales”; los centros neurálgicos de información a dos o tres empresas y además confiar más en los “paquetes como un todo” que en la implantación correcta de las tecnologías.

Es hora ya de crear un modelo estable, coherente y participativo para la creación de las aplicaciones de SL para la administración pública; ya es suficiente de tener aplicaciones implantadas incompletas e infuncionales y que además no podamos ni siquiera quejarnos de las mismas pues no existe la infraestructura para ello.

Considero sumamente importante que este proyecto puede ser el pilar fundamental de ello; SGHM (o como alguien quiera llamarlo) es una idea liberada bajo la FDL (Free Documentation License) y aspiro ir trabajando la idea todos los días y conseguir un lugar donde hacer un repositorio, un bugtraker, colocar a la disposición de la comunidad un wiki, un centro de sugerencias, área de documentación y esperar la participación de todos y cada uno de los presentes en la comunidad de software libre; no esperemos a que la “Empresa de Producción Social Perico de los Palotes y compañia” gane acceso irrestricto a toda nuestra información (datos bancarios, CNE, onidex, inces, minsalud) y que ni siquiera tengamos la posibilidad de contribuir con una mejor arquitectura, una mayor seguridad o un mejor modelo de datos; que nuestra información fiscal, financiera, de dólares o de sunacoop se convierta en una simple transacción financiera entre A y B y uno como ciudadano soberano no tenga ni siquiera la posibilidad de saber si lo que está ahí detrás es seguro o algún loco (como Tascón) tiene acceso ilegal a los datos y hacen con mi vida lo que les viene en gana.

¿Acaso les gustaría que una persona cualquiera usando algún ataque no documentado, publique al mundo que son impotentes porque tuvo acceso a nuestra información médica de manera ilegal? …

Es menester como comunidad que empecemos a demostrar que verdadero y amplio desarrollo colaborativo es posible; ayudenme a demostrar que eso es así …

Acerca de phenobarbital

http://about.me/phenobarbital

Publicado el 6 mayo 2008 en contraloría social, Cultura Libre, Linux, PlanetaLinux, Política. Añade a favoritos el enlace permanente. 4 comentarios.

  1. Por lo general no dejo comentarios, sobre todo en tus post que son inmensamente largos, este en particular lo lei todo, sobre todo porque los recuerdos que tengo de lo que nos costó comenzar el proyecto del CMDAT acuden a mi y me provocan una gran tristeza, el CMDAT al final no cuajó, pero que literalmente parimos Alfredo Naime y mi persona, para conseguir los recursos, para que lo vieran con un proyecto que necesitaba desarrolladores y un esquema de trabajo colaborativo que permitiera integrar hasta los desarrollos de otras latitudes, para que entendieran lo estrategico de que se hiciera con software libre y estandares abiertos, cada idea una lucha. Entre otras cosas la idea no cuajó porque todo el mundo quiere ‘victorias tempranas’ que le permitan tomarse la foto y ser protagonista de la novela. Un proyecto como el SGHM + CMDAT no permite/admite tomarse la foto de forma instantánea, hay que trabajar y eso no vende ni parece atractivo. Mi querido Jesús el CMDAT es una de esas batallas que he perdido ‘por ahora’, no todas se ganan y comprendo tu decepción. Tu post hasta produce dolor. Besos.

  2. Gracias Jesús por este este articulo, es tan interesante que les pase el link a mis jefes para que lo digieran.

    Realmente Jesús el leer tu articulo me hizo recordar la realidad Venezolana en materia de software libre, que en lo que más se asemeja en la actualidad es a la parte de la historia del viejo testamento en el que Moisés ( Richard Stallman ) luego de escaparse de Egipto ( U.S.A ) con el pueblo de Israel ( Venezuela ) que eran esclavos ( de microsoft ) llegan al desierto ( el periodo de migración ), el sube a una montaña a buscar los mandamientos ( 4 libertades del software libre ) y al llegar ve a todo el mundo adorando al becerro de oro ( los programas FUD/freeware disfrazados de Software Libre ).

    No se si reír o llorar cada vez que veo reflejada esta realidad en mi entorno cercano:-/

  3. Richzendy, muy bueno el simil de la migración a “la tierra prometida” con la migración venezolana …
    un simil a agregar adicional?, que para llegar a la tierra prometida debemos pasar por el mar muerto! (la etapa donde todo el mundo pasa hambre y nada sirve!) …
    Nagui, que no te produzca dolor; al contrario, he comprendido algo que tu intentaste enseñarnos, ganemosle cariño a un proyecto, asumamolos como nuestro y hagamos que funcione, no importa si no se logra implantar, algún día alguien se verá beneficiado …
    Perdimos una batalla, pero no dejaré que se pierda la guerra, no sin pelear!

  1. Pingback: DbRunas - VENEZUELA: SGHM, Sistemas médicos, El soberano y los esclavitos

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: