RSS Feed del blog de Nessy

Archivo del Nessy Letter

Nicolás Gómez — Mon, 18 May 2026 10:00:00 GMT

Entre diciembre 2020 y julio 2022 escribimos el Nessy Letter, un boletín mensual donde compartimos noticias y reflexiones sobre informática en salud. Después de 19 ediciones decidimos parar (las razones están en Por qué descontinuamos el Nessy Letter).

Como el archivo original sigue vivo en Buttondown, dejamos acá un índice ordenado: cada edición con un título nuevo que resume lo que cubrimos esa vez y una descripción breve para decidir si te interesa abrirla.

Las ediciones

Julio 2022 — Cirugía con imanes, FemTech y el costo de Roe v. Wade

Robot Levita —cirugía magnética made in Chile— aterrizando en la salud pública, los riesgos de privacidad de las apps de salud femenina tras el fallo de la Corte Suprema de EE.UU., y un programa de telesalud mental para el personal sanitario chileno.

Leer edición →

Junio 2022 — Mujeres en salud digital, certificaciones en la nube y una app contra el sol

El programa de RECAINSA para cerrar la brecha de género en liderazgo healthtech, becas de All Cloud Chile para certificarse en Google Cloud, y la app SunSmart de la OMS que avisa cuándo aplicarte protector.

Leer edición →

Mayo 2022 — Crónica desde Reino Unido y el futuro de la telemedicina

Mi experiencia trabajando dos semanas desde UK, la reflexión de María Paz sobre por qué la telemedicina no va a desaparecer post-pandemia, y la visión Deloitte 2040: de tratar enfermedades a gestionar la salud con datos.

Leer edición →

Abril 2022 — Convocatorias healthtech, IA cardíaca y trabajar en Babylon Health

MedTech Innovation con USD 15K en juego para startups chilenas y argentinas, Claudia Prieto y su uso de resonancia magnética con IA para detectar riesgo cardíaco temprano, y la búsqueda activa de Babylon Health para mudarte a UK o EE.UU.

Leer edición →

Marzo 2022 — STEM con mentoría, data science gratis y emprender en salud

PROVOCA abre postulaciones para grupos subrepresentados en STEM, OpenSalud LAB lanza un bootcamp híbrido de 36 semanas en data science para profesionales de la salud, y el diplomado UDD en emprendimiento digital sanitario.

Leer edición →

Febrero 2022 — 100 mil virus nuevos, brechas en telesalud y niñas en IA

Serratus descubre 100K virus desconocidos analizando bases genéticas en la nube, las plataformas chilenas solo cumplen el 70% de los estándares de seguridad exigidos por el sistema público, y Technovation Girls Chile abre cupos para chicas de 13 a 18.

Leer edición →

Enero 2022 — Fondos para ciencia, analítica de cuarentena y ley de datos

Startup Ciencia 2022 con $7.350 millones para emprendimientos científico-tecnológicos (con incentivo a equipos liderados por mujeres), una plataforma chilena que midió el cumplimiento del confinamiento, y la nueva Ley de Protección de Datos Personales que acerca a Chile al GDPR.

Leer edición →

Diciembre 2021 — Teletriage al cierre, SNOMED en español y lo que aprendimos

Casi 100 mil solicitudes resueltas remotamente con teletriage (1 de cada 10 cerrada por teléfono, 2 días de tiempo medio), el primer eBook de SNOMED en español del Hospital Italiano, y el cierre del año con el diplomado UDD del equipo.

Leer edición →

Noviembre 2021 — IA contra el cáncer de mama, software de salud y Apposito en validación

Algoritmo desarrollado con el MIT y testeado en Chile para riesgo individualizado en mamografías, la plataforma QueHayEnSalud que registra software en más de 4.400 instituciones, y nuestra app Apposito buscando prestadores para validación.

Leer edición →

Octubre 2021 — Chile y su Política de IA, HL7 CORE e insurtech en alza

Lanzamiento de la Política Nacional de IA con foco en educación y transparencia algorítmica, la guía CORE de HL7 Chile entrando en validación pública, y el boom global de las insurtech (más de USD 6B invertidos).

Leer edición →

Septiembre 2021 — Receta electrónica al fin, FHIR a la chilena y ransomware que mata

Chile estrena su Sistema Nacional de Receta Electrónica con interoperabilidad HL7 FHIR, sale la guía de implementación localizada, y un estudio del Ponemon Institute: 1 de cada 4 prestadores reportó aumento de mortalidad tras ataques de ransomware.

Leer edición →

Agosto 2021 — Trabajo remoto en 9punto5, vacunas chilenas y sesgo racial en IA

Nuestra participación en la conferencia 9punto5 sobre trabajo remoto, anuncio de un curso de HL7 FHIR, datos chilenos de efectividad de vacunas COVID, y una investigación inquietante: los algoritmos pueden detectar la raza del paciente desde una radiografía.

Leer edición →

Julio 2021 — Enfermería que salva vidas, errores humanos y un Reino Unido sin tabaco

Estudio chileno: 41% más mortalidad cuando una enfermera atiende 18 pacientes versus 8. El 36% de las filtraciones de datos sanitarios viene de un error humano simple (entrega incorrecta de información). Y la meta UK 2030: bajar a menos de 5% de fumadores.

Leer edición →

Junio 2021 — Apple Health para tus cercanos, Aduhelm polémico y mezclar vacunas

Apple suma compartir datos de salud con cuidadores y detección automática de tendencias, la FDA aprueba Aduhelm —primer tratamiento para Alzheimer en 18 años— en medio de la controversia, y datos de un estudio sobre Pfizer como segunda dosis tras AstraZeneca.

Leer edición →

Mayo 2021 — FHIR no es plug and play, algoritmos sin impacto y telesalud regulada

Implementar FHIR requiere ~20% de customización por proyecto (contrario a lo que se asumía), solo el 27% de los algoritmos médicos aprobados con marca CE muestra impacto clínico real, y MINSAL exige certificación a las plataformas de telesalud.

Leer edición →

Abril 2021 — Lanzamos Apposito, viene el Connectathon y un Telegram para abuelas

Apposito abre con plan personal gratuito y plan de equipo de pago, las fechas del Connectathon FHIR (17-19 de mayo, inscripción hasta el 30 de abril), y Yayagram: un dispositivo precioso para que abuelos manden audios y reciban mensajes impresos por Telegram.

Leer edición →

Marzo 2021 — Apposito está en camino, cursos HL7 y embriones fuera del útero

Adelanto de Apposito como app de seguimiento de heridas con foco en privacidad, cursos de HL7 y FHIR disponibles en Chile y Argentina entre abril y junio, y un hito científico: investigadores cultivaron embriones de ratón fuera del útero.

Leer edición →

Febrero 2021 — Primer Nessy Letter: Chile líder en vacunación y un test de cáncer en orina

La edición inaugural. Estrenamos la serie “Informática para no informáticos”, Chile se posiciona como referente mundial en velocidad de vacunación, CENS lanza el sello de calidad para plataformas de telemedicina (89 UF), y The Blue Box: IA que detecta cáncer de mama desde una muestra de orina.

Leer edición →

Diciembre 2020 — Antes del Nessy Letter: ¿y qué pasa con el Blockchain?

La edición cero, un par de meses antes de bautizar el boletín. En realidad fue el reenvío del post Blockchain en Salud a la lista de correo: una respuesta sin humo a la pregunta recurrente en charlas de salud digital.

Leer edición →

Nueva versión de Cesar AI (v2)

Nicolás Gómez — Thu, 16 Jan 2025 14:00:00 GMT

Cesar AI es una aplicación web que transforma información de un paciente (en cualquier formato) a un recurso Patient de HL7 FHIR.

Es un experimento que construí el año 2023, con la idea de que podría ayudar a acelerar procesos de integración entre distintos sistemas informáticos en salud.

Ahora año 2026, aprovechando la Connectathon 2026, actualizamos la herramienta para que funcione (no lo estaba 😭) y para que use los últimos perfiles de HL7 Chile.

A continuación te explico sobre los cambios que hicimos.

Contexto - de dónde viene Cesar AI

Luego del evento de la Emprendethon año 2023, comencé a pensar en qué tipo de soluciones podrían ayudar a acelerar los proyectos de interoperabilidad en salud.

Si bien aprender a usar los estándares de interoperabilidad como FHIR es importante, a veces no es tan sencillo hacerlo.

Imagina un Centro Médico que quiere interoperar y que tiene su propia base de datos. En esta, tendrá información bajo un cierto esquema, que probablemente es muy diferente al formato de datos en FHIR. Así que para lograrlo, tenemos que escribir código que transforme desde el formato del Centro Médico a FHIR, lo cual toma tiempo y puede ser costoso.

¿Qué pasa si esa transformación se hace automáticamente? ¿Es posible crear un algoritmo que pase de un formato a otro de manera automática?

Ahora sí… Los cambios que hicimos

La herramienta tenía 2 problemas:

No funcionaba debido a la depreciación de la API de OpenAI.
No usaba los últimos perfiles de HL7 Chile.

Cambio #1: Actualización de la API de OpenAI

Cuando construí Cesar AI el Q1 del 2023, usé el modelo text-davinci-003 de OpenAI, que fue dado de baja, al parecer, en enero de 2024. Espero que la herramienta haya estado funcionando bien… pero al parecer llevaba mucho tiempo sin hacerlo 😭

Cuento corto, ahora la actualicé para que use gpt-4o-mini, que si bien no es lo último, me permitió no tener que hacer tantos cambios en el prompt. Posiblemente lo actualizaré a 5.1 en unas semanas.

Cambio #2: Actualización de la forma en que el LLM procesa los datos

En la primera versión de Cesar AI, el trabajo del LLM era procesar la información del paciente y te entregaba un CSV estructurado. Luego, el código de la aplicación misma se encargaba de convertir el CSV a FHIR:

Input de usuario (csv, txt, json) → LLM → CSV → Código de la aplicación → FHIR

Esto fue porque en esos tiempos no existía la posibilidad de que los modelos entregaran respuestas de tipo JSON de forma nativa, y no había una manera de forzar que el texto generado fuera un JSON válido (de manera simple). Además, generar un JSON consume más tokens que generar un CSV, es decir, es más costoso (por eso herramientas como Toon están siendo tan populares).

Luego, OpenAI introdujo soporte de respuestas tipo JSON (“JSON Mode”), pero esto no estaba libre de problemas. Una cosa es que te respondiera un JSON, pero otra muy distinta es que ese JSON tuviera la estructura correcta. Recién en Agosto del 2024 comenzaron a soportar “output” estructurado, donde puedes especificar cómo debe ser la respuesta del LLM.

Así que ahora, cuando solicitamos que el LLM genere un JSON, le decimos que debe tener la siguiente estructura:

rut: string | null - RUT del paciente
nombres: string - Nombres de pila (sin apellidos)
apellido_paterno: string - Apellido paterno
apellido_materno: string | null - Apellido materno (opcional)
genero: enum["male", "female", "other", "unknown"] - Género
telefono: string | null - Número de teléfono
email: string | null - Correo electrónico
address: string | null - Dirección
birthday: string - Fecha de nacimiento (formato YYYY-MM-DD)

Y el código de la aplicación se encarga de convertir eso a FHIR válido:

Input de usuario (csv, txt, json) → LLM → JSON (formato propio) → Código de la aplicación → FHIR

Si bien generar este JSON requiere más tokens que generar un CSV, es decir, es más costoso, ahora nos aseguramos de que tenga la estructura correcta, lo cual es mucho más fácil de lograr que al pedir un CSV.

¿Por qué no generar el JSON FHIR directamente? Bueno, si has escrito un recurso FHIR a mano, te darás cuenta de que es bastante verboso. Esta simplificación es para reducir el costo de generación (tokens!), y para reducir la posibilidad de errores al momento de que el LLM genere el JSON.

Cambio #3: Actualización de los perfiles de HL7 Chile

Una vez arreglé el problema de la API de OpenAI, me di cuenta de que el LLM no cumplía con los perfiles de HL7 Chile actuales. Así que lo primero que hice fue lograr que el resultado fuera compatible con CL Paciente.

Algunos problemas que tuve estaban relacionados con códigos que se usan en la dirección. Por ejemplo, los datos que tenía antes usaba “Región Metropolitana” como display, pero el perfil de HL7 Chile te pide “Metropolitana de Santiago”.

El nombre de display para CSCodRegionCL#13 debe ser 'Metropolitana de Santiago',no 'Región Metropolitana'

Luego me puse ambicioso y quise que el resultado cumpliera con MINSAL Paciente, que es el que usamos durante la Connectathon 2026.

Aquí tuve que hacer más cambios, ya que este pide más información que CL Paciente. Por ejemplo, birthDate y isDeceased son obligatorios en Minsal Paciente, pero no en CL Paciente. Agregué estos campos, y por supuesto que isDeceased es false por defecto.

Cambio #4: Visualización del JSON

Esto es más un detalle que una mejora, pero pensé que sería útil tener un formateador de JSON más bonito en la interfaz. Así que, le pedí a Claude Code que mejorara ese aspecto e instaló json-viewer.

Resultado

Ahora la herramienta funciona y cumple con los perfiles de HL7 Chile actuales. Está disponible en cesar.codeness.io.

Si pillas algún problema o tienes alguna sugerencia, puedes escribirme a mi LinkedIn.

Nuestra experiencia en la Connectathon 2025

Nicolás Gómez — Tue, 14 Jan 2025 13:52:57 GMT

Este año fuimos a la Connectathon 2025, un evento donde distintos equipos pusieron a prueba sus conocimientos sobre interoperabilidad para hacer que los sistemas de salud conversaran entre ellos.

A diferencia de años anteriores (el 2024 éramos el grupo llamado «Galletas de Coco» 🍪), ahora con Eliana asistimos como monitores, así que pudimos ver el evento tras bambalinas.

Nuestro rol fue ayudar a los grupos a avanzar con los desafíos; algunas de las labores fueron:

Orientarlos para entender los enunciados y avanzar en cada ejercicio.
Guiarlos en el uso de las guías de implementación.
Ayudar a detectar errores en sus códigos.
Levantar errores técnicos de los servidores FHIR (que los encargados solucionaban en tiempo récord)

Fue agotador, quizás más que nuestra experiencia como participantes en años anteriores 😅, pero resultó muy gratificante ver el nivel de avance de los grupos.

Es genial ver cómo ha crecido este evento. Pasamos de ser unos cuantos grupos el año 2023, a decenas este año! Para el 2026 no sé cómo harán para organizar a tantas personas 😆

PD: Artículo basado en mi post en LinkedIn. Lo siento! No pudimos detallar tanto nuestra experiencia como los años anteriores (2023, 2024)

Nuestra experiencia en la AI Hackathon 2024

Nicolás Gómez — Mon, 09 Sep 2024 20:00:00 GMT

Chile 🇨🇱 fue el anfitrión de la primera hackathon oficial de OpenAI en Latinoamérica 💕, un evento que se realizó del 23 al 25 de agosto.

En este artículo, compartiré nuestra experiencia, lo que construimos y algunos aprendizajes 😃.

El evento

La hackathon se llevó a cabo de manera presencial en el edificio de la Cámara Chilena de la Construcción, en Las Condes, Santiago. Allí, 32 equipos, con más de 150 participantes, se reunieron para construir prototipos que usaran inteligencia artificial (IA) a través de las tecnologías de OpenAI.

Foto obtenida de https://gallery.communityos.io

Paralelamente a la competencia, se realizaron charlas sobre IA, que puedes ver en YouTube. En este artículo, me centraré en la hackathon, ya que no tuvimos la oportunidad de asistir a las charlas 😓.

Temáticas propuestas

El evento fue anunciado a principios de junio de este año. Para participar, debías elegir una categoría entre las siguientes:

A continuación te contaré cómo fue postular y cuál elegimos nosotros 😊

La inscripción y nuestra elección de temática

Eran las 2AM. Yo le estaba leyendo la postulación de la hackathon a Eli antes de hacer click en “Enviar”. Estábamos agotados 😴, había sido un día largo y bastante movido (veníamos llegando de un tour en Lisboa).

No muy convencida, me dijo dale!, Así que envíe la postulación.

Aquí una selfie con nuestros guías de @rsailing_tours en el tour de Lisboa, antes de postular

Estábamos como nómadas digitales en Europa (de hecho, daremos una charla en la 9punto5 sobre esto, guiño guiño 😉) por lo que, como puedes imaginar, dejamos la inscripción para último minuto.

Postulamos a la categoría de “Mitigación y adaptación al cambio climático” con un proyecto que ayuda a buscar vivienda considerando los efectos del cambio climático (nombre provisional: “Where to Live”).

La idea surgió después de una lluvia de ideas con Mauricio Chiong, experto en Climate Tech (lo invitamos a participar, pero quizás no estaría en Chile para la hackathon), y de una búsqueda en Reddit 😂 — r/climatechange/ es una mina de oro.

Nos habría encantado postular un proyecto en el área de salud, donde Eli y yo tenemos experiencia, pero supimos por una publicación en LinkedIn que Cambio Climático no estaba recibiendo muchas postulaciones, así que había más chances de quedar en ella.

Decidimos priorizar la temática sobre nuestras preferencias, ¡y funcionó! Porque quedamos seleccionados 😉.

Nuestro equipo

Eliana Quijada (LinkedIn): Enfermera y Full-Stack Developer en Hospital Digital (MINSAL).
Nicolás Gómez (LinkedIn): Software Engineer en Pauca Technologies LLC.

Nuestro equipo fue solo de dos personas. Más que por elección, fue por conveniencia. Como estábamos de viaje, nuestras mañanas eran para pasear y nuestras tardes/noches para trabajar, lo que hacía muy complicado coordinar una postulación con nuestros amigos en Chile.

Creo que fuimos el único equipo de solo dos personas, y no sé si eso fue bueno o malo 😂.

Nuestra solución

Inicialmente postulamos con la idea de “Where to Live”, una plataforma que ayudaría a las personas a buscar vivienda considerando los efectos del cambio climático.

Sin embargo, durante la hackathon, decidimos cambiar el enfoque y construir algo diferente: La Comarca Segura, una herramienta diseñada para ayudar a las comunidades a mitigar las consecuencias del cambio climático.

Este cambio de rumbo se debió a tres factores clave:

“Where to live” era una propuesta más individualista, y la hackathon enfatizaba mucho el sentido de comunidad.
Los datos que teníamos estaban mayormente a nivel comunal o regional, mientras que “Where to Live” requería información más geolocalizada.
Además, el “impacto de la solución” era parte de la pauta de evaluación. Consideramos que una propuesta enfocada en las comunidades tendría un mayor impacto.

Estas cosas las pensamos también por el feedback que nos dieron los mentores.

Pensamos en La Comarca Segura como una plataforma que ofrezca recomendaciones específicas y adaptadas a cada comuna, según los riesgos particulares que enfrentan, como inundaciones o incendios.

Dado que solo teníamos dos días y éramos solo dos personas, decidimos acotar el proyecto y centrarnos en las inundaciones, ya que representan el 25% de los eventos climáticos en Chile y tienen graves consecuencias económicas y de salud, mucho más allá de que se te moje la casa (algo que mucha gente desconoce 🙄).

A futuro, la plataforma podría expandirse para cubrir otros eventos climáticos como incendios y terremotos, entre otros.

El nombre La Comarca Segura fue idea de ChatGPT. Nos gustó porque transmite la seguridad de una comunidad unida, especialmente con el 18 de septiembre a la vuelta de la esquina, cuando en Chile nos sentimos como hobbits comiendo y celebrando. Aunque nos dio un poco de cringe, encajaba 😅.

Tour por La Comarca Segura

La plataforma te pregunta por una Región y Comuna:

Luego lo primero que te muestra es un análisis de Amenaza, Exposición y Riesgo:

Junto a recomendaciones comunales:

Y finalmente un pronóstico de Precipitaciones:

Junto a consejos para los vecinos:

Aquí un pequeño video (no tiene audio):

Programación

Esta sección es un poquito más técnica 🤓, el repositorio es público y lo puedes ver en GitHub: codeness-io/la-comarca-segura (está igual a como lo presentamos).

Stack tecnológico

Next 14
El AI SDK de Vercel para integrarnos con OpenAI
MUI como librería de diseño

Nos fuimos por lo seguro: con Eli tenemos experiencia en React, y como era una aplicación más “full-stack”, decidimos irnos por el framework Next, que lo es.

API de datos

Utilizamos los mapas de riesgo climáticos para Chile, que son parte de un proyecto del Ministerio del Medio Ambiente del Gobierno de Chile.

En particular, usamos los datos de Inundaciones.

Cómo usamos OpenAI

El prototipo lo armamos de forma incremental:

Mostrar una descripción sencilla del riesgo de una comuna en base a sus indicadores
Mostrar recomendaciones a nivel comunal
Mostrar recomendaciones a nivel personal

Para la primera etapa, utilizamos los datos de inundación, que consisten en 80 columnas (la mayoría son indicadores) y 346 filas (una para cada comuna). No tiene sentido entregarle todo el Excel a OpenAI, esto es derrochar créditos, así que escribimos el siguiente Prompt:

Eres un asesor de gobierno sobre riesgo y mitigación de consecuencias del cambio climático en Chile.

Tu objetivo es explicar de manera simple (ELI5) los principales riesgos que vez en una comuna específica.

Para esto, te entregaremos indicadores sobre inundaciones de la comuna a analizar.

Los indicadores que te entregaremos son los siguientes (CSV):

${attributesText}

Tu misión es explicar de manera simple los riesgos que ves en la comuna a analizar.

La parte que dice ${attributesText} se reemplaza por la descripción de las 80 columnas pero en formato CSV (que usa menos tokens que JSON).

Luego, cuando una persona consulta en la página por una comuna específica, buscamos los datos de la comuna, y junto al prompt anterior, agregamos la consulta específica:

La comuna a analizar es: ${floodData.properties.NOM_COMUNA}

Los indicadores para esta comuna son: ${JSON.stringify(floodData.properties, null, 2)}
  
Para responder, hazlo en formato markdown, es español, y no incluyas los valores de los indicadores. Puedes marcar con negrita los puntos más importantes.

La estructura que debes seguir es la siguiente estructura JSON:

{
  "risk": "(Amenaza de inundaciones)",
  "exposition": "(Cuántas personas están en riesgo)",
  "risk_vs_exposition": "(Riesgo - amenaza vs exposición)",
  "improvements": ["Sugerencia de mejora 1", ..., "Sugerencia N"]}
}

Le pedimos un objeto JSON como respuesta, lo bueno es que con el SDK de AI de Vercel esto es muy fácil de hacer:

  // Primero defines el objeto
  const expected = z.object({
    risk: z.string(),
    exposition: z.string(),
    risk_vs_exposition: z.string(),
    improvements: z.array(z.string())
  })

  // Luego lo pides
  const { object } = await generateObject({
    model: openai('gpt-4o'),
    schema: expected,
    // ⬇️ es el primer prompt (el que tiene la definición de indicadores)
    system: getFloodSystemPrompt(),
    // ⬇️ es el segundo prompt, que tiene la comuna en particular
    prompt: await getFloodUserPrompt(commune),
  });

Todas las piezas juntas

Dada una comuna, conseguimos sus indicadores (consultando ARCLIM) y le pedimos a OpenAI que haga una explicación en fácil, y también le pedimos recomendaciones.

Luego, usamos la API de Open Meteo para datos de precipitaciones de los próximos 15 días. Ejecutamos un algoritmo sencillo para saber si estas precipitaciones serán extremas, para así mostrar las recomendaciones vecinales ante el frente meteorológico.

A continuación puedes ver un diagrama que resume todo lo anterior:

Diseño

Pasamos del mock-up que hizo Eli en un cuaderno (17:00 hrs del sábado):

A una primera versión (9PM del sábado):

Al reporte propiamente tal (12:00PM Domingo)

También hicimos una Landing Page, para presentar directamente desde el prototipo y no de una diapositiva:

Aquí nos gustaría agradecer a Valentina Reyes (mentora en UX, aquí su LinkedIn) que nos dio consejos súper buenos para mejorar la presentación de nuestra solución 💕

Resultados de la competencia

La evaluación fue en dos partes:

Clasificación a la final: los 32 equipos debían presentar su solución en 5 minutos, poniendo énfasis en el impacto y en lo avanzado durante la hackathon.
La final: 12 equipos seleccionados presentaban ante los jueces y el “mundo entero” su solución, también en 5 minutos.

Si bien no quedamos en la final, nos fuimos satisfechos con nuestra participación. Logramos tener un producto completo que funciona, a pesar de que nos costó decidir qué construir. Además, Eli se lució en la presentación.

Obviamente, íbamos con la intención de ganar y quedar en la final, pero hay hartas cosas que nos perjudicaron y que quedan como aprendizajes a futuro.

Eli Presentando La Comarca Segura. Créditos a https://gallery.communityos.io

Aprendizajes para el futuro

Siendo bien honesto, nuestra solución no nos convencía a nosotros mismos de su utilidad e impacto 😂. No porque no lo viéramos como algo importante, sino que por falta de conocimiento del tema, nos costaba imaginarnos su aplicación en el mundo real. Por este mismo punto, no sabíamos muy bien qué otros datos útiles podríamos obtener para así hacer más dinámico el reporte.

El feedback que recibimos es que si bien la presentación estuvo bien, hubo un vacío entre la información mostrada y el impacto para las personas que la recibían, ya que estos eran un poco genéricos.

No sé si mejorar eso nos hubiese hecho quedar en la final, pero fue algo que teníamos en el radar y que no alcanzamos a implementar. Quizás en vez de invertir tiempo en una “landing page”, podríamos haber hecho que los consejos fueran más específicos, y además, en preparar una presentación (”PPT”) como el resto de los grupos, para vender mejor la solución y su desarrollo a futuro, así dejar claro que no era solo inundaciones, sino que también podríamos incluir más riesgos.

Entonces, resumiendo estos aprendizajes:

Ojalá tener a alguien que sepa mucho de la temática en el equipo
Presentar con slides 😂
SIEMPRE pensar en lo que construyes en la hackathon como si fuera un producto que vas a vender

Feedback de la hackathon

Lo Bueno

Participar fue ganar por todos lados: muy buena comida, los créditos de OpenAI quedaron para el equipo (200 USD 🎉).
La comida fue genial, tanto en sabor como en abundancia 🐷 (esto es algo que los eventos suelen fallar, pero aquí no!)
El diseño del evento quedó genial, las instalaciones se sentían como si estuviéramos en una sede de OpenAI.
Había muchos mentores, los que nos asignaron eran muy buenos, nos dieron tips útiles, sobre todo en cómo orientar la solución.
Las instalaciones de la Cámara Chilena de la Construcción fueron muy buenas, harto espacio, sillas cómodas para trabajar.

Sí. Le saqué foto a la comida, porque la encontré genial.

Lo no tan bueno

Con Eli somos muy estructurados y nos gusta tener pautas para este tipo de actividades, aquí hubo una, pero no sentimos que fuera tan clara.

¿Teníamos que vender un producto o no?

Mencionaron varias veces que era una hackathon más “hacker” que una donde se venda un producto propiamente tal. De hecho, en algún momento los organizadores mencionaron que no perdieran el tiempo haciendo muchas diapositivas, porque lo importante era tener algo corriendo en nuestros computadores.

Nosotros tomamos esto como un “no hagan diapos”. Pero, algo entendimos mal, ya que muchos grupos sí lo hicieron. Hace todo el sentido del mundo, ya que es un súper buen apoyo en el caso de quedar en la final.

¿Y qué pasó con el Cambio climático?

En la inauguración, se mencionó que trabajaríamos en problemas importantes como el “Cambio Climático”, pero si viste la final, solo un grupo era relacionado con esta temática.

Sé que no tuvo muchas postulaciones, y creo que eso da cuenta de la dificultad de hacer un proyecto en ese ámbito. ¿Pero de verdad no había más material para la final?

Palabras finales

La “AI Hackathon” fue una experiencia inmersiva, donde todos los participantes estaban de cabeza construyendo sus proyectos, según nos contaron, varios pasaron de largo sin dormir (¿o será la juventud? 😂)

La organización estuvo excelente. Se cumplieron los tiempos, lograron que muchas personas estuvieran trabajando un sábado y un domingo, por muchas horas.

Felicidades al grupo ganador de “Justa”, su presentación transmitió mucha pasión, motivación, y cumplieron con los tiempos a la perfección. Hubo muchos grupos trabajando cosas muy interesantes y entretenidas, en la final estábamos con Eli creyéndonos jurado debatiendo qué grupo debía ganar en cada categoría 🤭.

Me voy con una experiencia muy positiva, a pesar de las cosas que comenté en la sección anterior.

Si bien no quedamos en la final, me pareció muy entretenido trabajar codo a codo con mi compañera y esposa Eli 💕

P.D: si quieres saber más sobre cómo fue el evento, te recomiendo leer el artículo de Fintual: “Por qué el evento oficial de OpenAI en Chile fue tan importante: la AI Hackathon”, escrito por Omar Larré.

Nuestra experiencia en la Connectathon 2024

Nicolás Gómez — Wed, 24 Jan 2024 15:00:00 GMT

Este año fuimos a la Connectathon 2024, un evento donde distintos equipos pusieron a prueba sus conocimientos sobre interoperabilidad para hacer que los sistemas de salud conversaran entre ellos.

A Eli y a mí nos encanta el mundo de la salud digital, así que cuando supimos que se realizaría una nueva versión del evento, nos inscribimos inmediatamente. Lo mejor fue que a aquellos equipos que además participamos en los talleres previos, se nos otorgó un certificado de validación técnica.

Esta vez fuimos bajo el nombre de equipo “Galletas de Coco” 🍪. Como participó el MINSAL, muchos equipos tenían nombres muy serios, así que el nuestro llamó la atención. Al final del artículo comentaré el por qué del nombre 🤭.

En este evento, esperábamos aprender más sobre el estándar HL7 FHIR, entender el contexto de interoperabilidad en Chile, conocer más personas que estuvieran en el rubro y ganar la Connectathon. Logramos todo esto, excepto “ganar”, ya que esta vez no fue una competencia 😣 jaja.

Si participaste en la organización del evento, ¡Muchas gracias! La pasamos muy bien, comimos rico y por supuesto aprendimos un montón.

A continuación dejaré una reseña del evento, lo que construímos y parte de lo que aprendimos.

Día 1: Miércoles - El Comienzo de la Aventura

El evento se realizó en el Duoc UC sede San Joaquín, y comenzó a las 9 am.

Como he estado trabajando remotamente desde mi casa del año 2017, esto realmente significó salir de mi zona de confort 😂

Luego, estando allí, me llevé una grata sorpresa al ver que el auditorio estaba repleto. Parecía que había más de 200 personas.

Durante el día, se impartieron distintas charlas, las cuales quedaron grabadas en YouTube. También hubo coffee breaks y almuerzo incluido. En mi caso, eran tantas las personas, que preferí salir a comer afuera.

La jornada concluyó con un cóctel donde los asistentes pudimos interactuar:

Tuve la oportunidad de conversar con algunos ingenieros del CENS, como José y Marcelo, con Jorge (CERO), Paulo (OpenSaludLab) y Pablo (Hospital Digital) (Hola! 👋)

De qué se habló durante el evento

A modo de síntesis, las 3 ideas más compartidas a lo largo de la jornada sobre la integración de sistema de salud fueron las siguientes:

La parte técnica es la simple (le sumaría que no por eso es fácil 😁)
Es complicado estandarizar procesos de salud para adaptarlos a casos de interoperabilidad
La parte difícil es coordinar a las personas 😮‍💨

Esto, sumado al contexto en que Chile se encuentra respecto a interoperabilidad, resulta muy interesante. Hace 1 año, en la Connectathon anterior, hubo mucha menos participación. La gran diferencia ahora, es que contamos con la participación del MINSAL, y además, nos encontramos en un contexto distinto. Por ejemplo, a nivel normativo:

Proyecto de Ley que modifica Deberes y derechos de las personas (20.584): con el objeto de establecer la interoperabilidad de las fichas clínicas.
Ley Telemedicina (20.541): la ficha clínica electrónica y los sistemas que la soporten deberán estar diseñados para interoperar.
Ley Ciberseguridad (aprobada en diciembre 2023): considera al sector salud como servicio esencial.

Esto, sumado al gran trabajo de HL7 Chile, nos acerca cada vez más a que todos los sistemas de salud en Chile conversen entre ellos 💕

Queda un largo camino, pero es cierto que en un año se avanzó mucho.

Reflexiones personales

En la mayoría de las ocasiones, cuando se discutía sobre interoperabilidad, solía quedarme con la impresión de que, aunque el mensaje era atractivo, había pocas posibilidades de concretar acciones.

Sin embargo, esta vez observé algo distinto. Las iniciativas ya están en marcha, existe voluntad, se han establecido normativas, hay tecnología disponible y existe el talento.

Por lo tanto, me llevé una excelente impresión del primer día; superó mis expectativas 👏.

Día 2: Jueves - Manos a la Obra en el Connectathon

Para participar en la Connectathon, tuvimos que inscribirnos en uno de los tracks disponibles, que eran:

Tiempos de espera
Receta electrónica
Identificador de pacientes

Escogimos el track de “Tiempos de Espera” porque nos parecía técnicamente el más desafiante.

Este track se enfocó en el proceso de solicitud de interconsulta (SIC) desde el nivel primario de salud (APS) a una consulta de especialidad en el nivel secundario, mediante el intercambio de recursos HL7 FHIR con la plataforma interoperable de Tiempos de Espera.

El enunciado está disponible aquí.

Desafíos del primer día

Si viste el enunciado, podrás notar que había muchos ejercicios. Realmente el tiempo para dedicarles no era mucho, ya que entre las sesiones de trabajo había charlas y otras actividades como coffee-breaks y almuerzo.

Nada que decir con respecto a los breaks para alimentarse 😂, sin embargo, creo que sería beneficioso tener sesiones de trabajo más extensas, para poder entrar en “el flujo” y avanzar sin interrupciones.

Nosotros avanzamos bien porque éramos 2 personas (lo que facilitaba la comunicación), conocimientos previos (tanto en el área de salud, como trabajando con FHIR) y nos dividimos los ejercicios.

Resultados del primer día

Logramos completar 4 ejercicios al final del día (50%). Por lo que observamos, fuimos de los pocos grupos que alcanzaron ese nivel el primer día.

Había ciertos aspectos confusos en las guías de implementación, pero en general estaban bastante bien.

Lo que más me llamó la atención fue que ciertas operaciones duplicaban la información. Sin embargo, nos explicaron que eso dependía de la implementación del servidor FHIR. Una vez que entendimos esto, pudimos avanzar con más confianza.

Día 3: Viernes - Conectando Puntos y Clausura

Este día tuvimos menos charlas que el anterior, por lo que todos tuvimos más tiempo para dedicarnos al desafío.

Continuamos con la división de ejercicios, trabajando en dos simultáneamente. Así, logramos terminar el desafío cerca de las 14:30 🎉

Una vez que terminamos, pensamos en tomar otros desafíos, pero nos enteramos de que crear un “frontend” para los datos (mostrarlos de cierta manera) era considerado el nivel legendario 😎, y quisimos alcanzar ese nivel.

Nos pusimos manos a la obra y desarrollamos una aplicación en menos de dos horas:

Puedes ver el resultado en https://tiempos-de-espera.netlify.app/ ya que los servidores todavía están disponibles. En resumen es una mini aplicación que permite buscar el estado de la interconsulta a partir de su identificador, mostrando un pequeño historial de sus diferentes estados.

En cuanto a stack tecnológico, optamos por utilizar lo siguiente:

React para el frontend, empleando Create React App. Sí, está depreciado, y no, no nos interesa.
Express para el backend, funcionando como un proxy para hacer llamadas al servidor real de FHIR.

Ceremonia de Clausura

Aunque no fue una competencia, recibimos reconocimiento por ser uno de los grupos que completó todos los desafíos en el track de tiempos de espera.

En la imagen, somos “GDC46”. También felicitamos a “Pronova61”, que logró el mismo alcance 👏.

Según lo que mencionaron los organizadores, hubo mejores resultados de los esperados, ya que muchos equipos lograron avanzar, incluso algunos sin tener nada de experiencia en el estándar.

E incluso varios equipos logramos llegar a construir un frontend que utilizara los servicios trabajados durante estos 2 días.

Lo que es súper importante, porque demuestra que en estas jornadas de trabajo, cuando existe la motivación, se puede compartir mucho conocimiento.

Conclusiones Generales

Si el año pasado mencionamos que fue emocionante ver a tantas personas reunidas con un mismo foco, este año se reafirma, ya que los equipos participantes eran muchos más. Y resulta gratificante ver a tantos representantes del servicio público, como de empresas privadas.

Desde el punto de vista técnico, también hemos podido ver cómo vamos madurando poco a poco como país en temas de interoperabilidad, abordando procesos más complejos, como lo es el seguimiento de una interconsulta.

Valoramos lo importante que es como desarrolladores, ser partícipes no sólo de aprender del estándar, sino también de entender las diferentes partes del proceso y participar de estas instancias que nos permiten validar y ayudar a mejorar las guías de implementación que se han desarrollado para nuestro país.

Estos eventos, además de enseñarnos cosas técnicas y permitirnos conectar con otras personas, muchas veces funcionan como una inyección de energía, para recordarnos el propósito final de las líneas de código que escribimos cada día, que va más allá de sólo crear una bonita aplicación o un código de alta calidad. Si trabajamos en salud, lo escribimos para impactar y mejorar la salud de las personas.

Volvemos a agradecer a los organizadores, se vieron muchas mejoras con respecto al año pasado (y eso que el año anterior ya fue una gran experiencia). El cariño que le ponen a este trabajo se nota en los detalles, como por ejemplo, nuestra medalla de reconocimiento.

Extra: ¿Por qué nos llamamos “Galletas de Coco”?

El origen de “Coco” se remonta a la edición de 2023, cuando participamos representando a las empresas para las que trabajamos, Codeness y Continuum. Ese año, nos apodamos “Co-Co” 🥥 en alusión a ellas.

Así que esta vez era natural llamarnos “Coco”. El problema surgió porque nos pedían un equipo de tres personas. Al consultar si era posible participar solo dos, nos respondieron: “consíganse un galleta”.

Galleta: Generalmente en nuestras “Pichangas” faltan algún jugador y se busca cualquier reemplazante. A este se le llama Galleta, que destaca por no vestir como el resto y, muchas veces, no conocer a nadie en el campo de juego. – Fuente

Afortunadamente, unos meses antes, un amigo me había consultado sobre interoperabilidad en el sector salud, un campo en el cual él estaba incursionando. Aprovechando la oportunidad, lo invitamos a ser nuestro tercer miembro.

Así completamos nuestro equipo. Dado que su incorporación surgió de la necesidad de “encontrar un galleta”, decidimos llamarnos “Galletas de Coco”, un nombre que refleja con humor nuestro inicio.

Construyendo Cesar AI

Nicolás Gómez — Tue, 04 Apr 2023 14:00:00 GMT

Cesar AI es una aplicación web que transforma información de un paciente (de cualquier formato) al recurso Patient de HL7 FHIR.

Es un experimento que construí, que podría ayudar a acelerar procesos de integración entre distintos sistemas informáticos en salud.

A continuación te explico de qué trata el experimento, cómo lo construí y consideraciones a futuro de este tipo de aplicaciones.

Motivación

Luego del evento de la Emprendethon, comencé a pensar en qué tipo de soluciones podrían ayudar a acelerar los proyectos de interoperabilidad en salud.

Si bien aprender a usar los estándares de interoperabilidad como FHIR es importante, a veces no es tan sencillo hacerlo.

¿Qué pasa si esa transformación se hace automáticamente? ¿Es posible crear un algoritmo que pase de un formato a otro de manera automática?

Pruebas Preliminares

El último tiempo han aparecido varias aplicaciones que procesan texto, que son capaces de analizar sentimientos en un texto e incluso de crear contenido por ti. Muchas de ellas usan herramientas proveídas por una compañía llamada OpenAI.

En redes sociales me topé con comentarios que decían que estas herramientas eran buenas para transformar datos de un formato a otro, que es justamente lo que yo quería hacer. Así que un siguiente paso es probarlas.

Para ver si funciona para mi caso de uso, hay que responder las siguientes preguntas:

¿Me sirven estas herramientas para transformar datos de un paciente a FHIR? (Prueba 1)
¿Puedo usar las herramientas desde mis propios programas? (Prueba 2)
¿Es fácil usarlas en mis propios programas? (Prueba 3)

Primera prueba: ¿Me sirven estas herramientas para transformar datos de un paciente a FHIR?

La forma más rápida de responder a esta pregunta es usando el modelo más fácil de usar y popular: ChatGTP. Si no lo logro con este, difícil que lo logre con los otros.

ChatGTP es un programa creado por OpenAI diseñado para procesar y generar texto en muchos idiomas. Funciona como un asistente al cual le puedes escribir preguntas sobre distintos temas, y este hará lo posible por responder.

Por ejemplo, le puedes preguntar “explica FHIR a un niño de 5 años” y te responderá algo como:

También puedes hacer solicitudes más complejas. Por ejemplo, si le pides que transforme datos no estructurados de un paciente a HL7 FHIR, te dará una respuesta suficientemente buena:

La respuesta fue esta:

{
  "resourceType": "Patient",
  "identifier": [
    {
      "system": "http://www.run.gov",
      "value": "66.2345.333-1"
    }
  ],
  "name": [
    {
      "family": "Organa de la Rosa",
      "given": [
        "Jan-Solo"
      ]
    }
  ],
  "gender": "unknown",
  "birthDate": "1961-04-03",
  "address": [
    {
      "line": [
        "Av Los Caudillos, número 67"
      ],
      "city": "Valparaíso",
      "district": "Valparaíso",
      "postalCode": "xxxxx"
    }
  ]
}

Así concluyo que estas herramientas sí permiten transformar datos de un paciente a FHIR.

Segunda prueba: ¿puedo usar estas herramientas desde mis propios programas?

En informática, cuando quieres conectar un sistema informático con otro, se usa algo llamado “API”. Por ejemplo, si tengo una aplicación donde quiero usar el valor actual del dólar, en vez de actualizar el valor a mano cada cierto tiempo, puedo usar un servicio externo (”API”) que me entregue el número actualizado.

Las API permiten que nuestros programas usen sistemas externos para lograr distintas tareas. En mi caso, necesito acceder a una API que me permita hacer preguntas como lo hago con ChatGTP.

La buena noticia es que OpenAI ofrece una API sobre la cual desarrolladores y empresas pueden construir aplicaciones. Me atrevo a decir que la base de su negocio es ofrecer este tipo de herramientas y cobrar por uso.

Nota: en OpenAI API puedes ver todas las características y ejemplos de lo que puedes lograr.

Si vas a la página de Playground, puedes jugar con la herramienta sin necesidad de usar la API directamente. Para probar, le entregué el mismo texto que a ChatGTP:

La respuesta es la siguiente:

{
  "resourceType": "Patient",
  "id": "66.2345.333-1",
  "name": [
    {
      "use": "official",
      "family": "Organa de la Rosa",
      "given": ["Jan", "Solo"]
    }
  ],
  "gender": "male",
  "birthDate": "1961-04-03",
  "address": [
    {
      "line": ["Av Los Caudillos, número 67"],
      "city": "Valparaíso",
      "state": "Valparaíso",
      "postalCode": "Región de Valparaíso"
    }
  ],
  "extension": [
    {
      "url": "http://example.org/age",
      "valueAge": {
        "value": 61
      }
    },
    {
      "url": "http://example.org/visit",
      "valueDateTime": "2022-07-28T17:30:00"

De aquí hay cosas que no me gustaron. Por ejemplo, el RUT lo dejó como id, y la edad la colocó como una extensión. Además, el JSON está incompleto.

¿Por qué está incompleto? Pasa que las palabras que ingresas y las que te entregan se contabilizan en “tokens”, donde 1000 tokens equivalen aproximadamente a 750 palabras. En el PlayGround, el límite de tokens por defecto es 256, por eso no me da una respuesta completa.

Para mejorar la calidad de respuesta, tengo que mejorar el texto inicial que dice “Transforma los datos del siguiente paciente a FHIR”. Esta parte se le llama “prompt”, que son las instrucciones que le damos al modelo para así obtener las respuestas que queremos.

Si bien hasta ahora la respuesta deja mucho que desear, la pregunta inicial es si puedo usar la herramienta desde mis propios programas. La buena noticia es que hay una opción que dice “View Code” que te genera el código exacto para usar en tu aplicación, en el lenguaje de programación que desees:

Hasta ahora sé que puedo usar la herramienta en mis propios programas y que necesito mejorar las instrucciones que le doy para obtener mejores resultados.

Tercera prueba: ¿es fácil usarlas en mis propios programas?

El código que genera el Playground se ve bastante simple, así que ahora toca usar este código.

En la documentación hay un Quickstart tutorial, donde te explican lo básico que tienes que saber y te dan una aplicación base de ejemplo. En esta aplicación colocas un animal y te sugiere nombres:

Esta aplicación está construida con Next.js, que si bien no lo he usado anteriormente, conozco React y JavaScript al revés y al derecho.

El código es bastante sencillo. Hay una función llamada generatePromp que es lo que hay que cambiar para que en vez de solicitar nombres de animales, me entregue información de pacientes.

function generatePrompt(animal) {
  const capitalizedAnimal =
    animal[0].toUpperCase() + animal.slice(1).toLowerCase();
  return `Suggest three names for an animal that is a superhero.
Animal: Cat
Names: Captain Sharpclaw, Agent Fluffball, The Incredible Feline
Animal: Dog
Names: Ruff the Protector, Wonder Canine, Sir Barks-a-Lot
Animal: ${capitalizedAnimal}
Names:`;
}

Cambié la función a lo siguiente:

function generatePrompt(patient) {
  return `Transforma los datos del siguiente paciente a un recurso de HL7 FHIR:

${patient}

[INSERT]
`;
}

Nota: el texto [INSERT] es para indicarle al modelo donde tiene que rellenar la información.

El resultado, si bien estaba truncado, parecía ser un recurso HL7 válido:

Así concluye esta tercera prueba. Hasta ahora sé que es fácil usar la herramienta en mis propios programas, y que incluso tengo una base sobre la cual construir mi aplicación.

Resultado de las pruebas

Las pruebas fueron exitosas. A partir de un texto que tiene información no estructurada de un paciente, fui capaz de generar un recurso FHIR. Además, descubrí que usarlo en programas propios era sencillo.

Sin embargo, también me di cuenta de que no le estoy dando el enfoque correcto. Los costos son proporcionales a la cantidad de texto que entregas y a la cantidad de texto que recibes. El recurso FHIR tiene mucha información repetitiva, hay palabras que me sobran.

Debido a lo anterior, un mejor enfoque es pedir información del paciente en un formato texto. Por ejemplo:

Ya sé que el primer elemento entre los caracteres “|” es el RUT, el segundo elemento corresponde al nombre, y así. Gracias a esto, la respuesta es más barata porque usa menos “tokens”. Eso sí, ya no estamos hablando de FHIR, sino que es un formato muy parecido a CSV (donde la separación es con el carácter ”|”). Tendremos que pasar de este a FHIR, y para eso, hay que escribir código 😅

Construyendo Cesar AI

La prueba de concepto funcionó bien. Ahora toca armar un prototipo de herramienta que pueda transformar los datos de un paciente a su formato en FHIR, con el formato que usamos en Chile.

Diseñando el MVP: qué funciones debía tener

Fue natural mantener una interfaz parecida a lo que ocurre en el PlayGround de OpenAI: a la izquierda colocar una caja de texto para ingresar la información del paciente, y a la derecha, el recurso FHIR transformado.

Las funciones son 2:

Permitir ingresar datos a transformar.
Poder ver esos datos transformados en un recurso FHIR.

Construyendo el MVP: usando el código base de OpenAI

El código base de OpenAI es fácil de modificar.

Por ejemplo, en la siguiente imagen, podemos ver la función que entrega el resultado desde el servidor a la aplicación web. Aquí, cambié generatePrompt(animal) por una función nueva que creé, y también ajusté algunos parámetros del modelo. En particular, la temperatura la dejé en 0 para que el resultado que me entregara el modelo fuera siempre el mismo para un mismo input:

Notar también que estoy enviando como respuesta el recurso FHIR (variable resource), que es lo que muestro en la interfaz una vez haces clic en “Generar Recurso FHIR”.

En cuanto al Frontend:

Utilicé Bootstrap que es la librería para crear interfaces que más fácil se me da ocupar, aunque admito que es un poco mucho para el prototipo 😅.
Lo que ocurre una vez le das clic a “Generar Recurso FHIR”, es muy parecida a la del tutorial:

Nota: si quieres aprender a hacer data fetching con React, te recomiendo leer el artículo “Data fetching con React usando useState y useEffect” que escribí para Escuela Frontend.

Problemas y limitaciones: Google Maps al rescate

La primera versión funcionaba bien. Solo había un problema: las direcciones.

HL7 Chile definió un formato para guardar direcciones que básicamente tiene 4 componentes:

Line: Calle y número
City: Comuna
District: Provincia
State: Región
Country: País

Por ejemplo, la dirección “C. Arturo Prat 210, San Nicolás, Ñuble” se debe descomponer en:

Line: Calle Arturo Prat 210
City: San Nicolás (código 16305)
District: Punilla (código 163)
State: Ñuble (código 16)
Country: Chile (código 152)

Para lograr esto, hay que decirle a OpenAI que necesitamos la dirección con sus 5 componentes: línea, comuna, provincia, estado y país. Si bien el modelo detecta bien la dirección completa, es difícil que haga una buena descomposición. Hice las pruebas y además de que se equivocaba en la descomposición, el resultado entregado no es compatible con el listado de códigos definido por HL7 Chile.

¿Cómo descomponemos una dirección en sus componentes? Hay una API que lo hace muy bien: Google Maps.

De esta forma, Open AI se encarga de extraer la dirección, y luego Google Maps de descomponerla.

El último desafío es que Google Maps no entrega los mismos nombres que están definidos en los códigos de provincias de Chile. Por ejemplo, “Punilla” para Google es “Provincia de Punilla”. Así como este, hay otras provincias con inconsistencias parecidas.

Para mí es obvio que si Google me dice “Provincia de Punilla”, corresponde a “Punilla”. Pero programar eso no es tan sencillo, sobre todo considerando que Google no entrega el listado de provincias. Para solucionarlo, le pasé el listado completo de provincias al modelo de OpenAI, y luego le pregunto algo como: “¿a qué provincia corresponde este texto?”

Otra forma de hacerlo podría ser con una base de datos que permita hacer búsqueda por similitud. De esa forma, nos ahorraríamos llamados a OpenAI que estimo que es más caro.

Resultado final

El resultado final lo puedes ver aquí en vivo.

El diagrama de funcionamiento final:

Consideraciones a futuro

CesarAI es un prototipo que busca transformar datos de un paciente en cualquier formato a uno interoperable (HL7 FHIR), funciona bien, pero faltan cosas que mejorar:

Modelo de negocio: ¿hay mercado? En Chile, la interoperabilidad viene fuerte, entonces la cantidad de proyectos que necesitarán disponer datos en el formato interoperable van a ir en aumento. Además, una herramienta de este estilo podría ahorrar varias horas de desarrollo, y se puede cobrar en base a ese ahorro.
Ético y Legal: En Italia restringieron el uso de ChatGTP por razones de privacidad. Además, según este artículo, tampoco cumple con HIPAA, ya que estás entregándole información de paciente personal. Si bien en los términos de uso dicen no usar el contenido que entregas para mejorar sus servicios, también menciona que si quieres procesar datos personales, hay que entregar el aviso legal correspondiente.
Branding: El nombre se llama “CesarAI”, pero la verdad se me fue dejarlo solo en “Cesar”. “Powered by AI” no es un feature, es simplemente una característica interna.

Siguientes pasos

Debido a las consideraciones éticas y legales, creo que por ahora no es bueno usar una herramienta de este estilo para datos de paciente. Sin embargo, puede servir como una herramienta de estudio del estándar HL7 FHIR.

Alternativamente, habría que explorar si existen otros modelos que cumplan regulaciones estrictas como HIPAA y GDPR, y así actualizar la herramienta para que los use.

Finalmente, es posible explorar otras ideas que buscan solucionar la misma problemática. ¿Qué pasa si en vez de entregar datos de paciente, entregas el “formato” de tus datos? Cesar podría generar una función en cualquier lenguaje de programación que transforme tus datos a HL7 FHIR. Así, es posible contribuir a disminuir costos de implementación sin comprometer datos personales.

Nuestra experiencia en la Emprendethon 2023

Eliana Quijada — Mon, 23 Jan 2023 19:00:00 GMT

Después de una semana intensa, ganamos la “Emprendethon”, evento donde nos pasaron juguetitos nuevos con los que armamos dos prototipos de aplicaciones.

En este artículo, describiremos de qué trató este evento, cuáles fueron esas dos aplicaciones que construimos, qué ganamos y nuestras impresiones generales de la jornada.

¿Qué es la Emprendethon?

Durante la semana del 9 al 13 de enero, se realizaron en la ciudad de Valparaíso, Chile, dos importantes eventos para el mundo de la salud digital, la Connectathon y el Make Health Latam.

La Connectathon, estuvo enfocada a que distintos grupos pudiesen aplicar el uso del estándar HL7 FHIR, utilizando los perfiles adaptados para nuestro país.

En el Make Health, hubo charlas, paneles, workshops y una Datathon, en dónde los equipos estuvieron enfocados en utilizar bases de datos entregadas por diferentes organizaciones, para hacer Ciencia de Datos.

La Emprendethon funcionó de forma transversal a estos 2 eventos, y consistía en que emprendedores aprendieran a utilizar distintas herramientas en el ámbito de interoperabilidad y ciencia de datos, pero no solo desde el punto de vista técnico/académico, sino que también mostrar cómo lo vería un usuario ya sea profesional de salud o paciente, intentando transmitir la cadena de valor completa que nos entregan esos datos.

Connectathon

El desafío durante la Connectathon (días 1 y 2)

Para el primer desafío, bajo el alero de la Connectathon, se nos entregó un caso de uso donde el objetivo era que lográsemos guardar y consultar información de un paciente y sus diagnósticos.

Obviamente, los datos tenían que cumplir con estándares de interoperabilidad, para lo cual nos dieron acceso a un servidor FHIR disponibilizado por AWS, el cual contaba con las reglas de la guía core de Chile.

Además, utilizando algunas herramientas de AWS, debíamos construir una aplicación web que se conectara al servidor FHIR y consultara los datos almacenados. La herramienta debía ser publicada en una URL de manera de que cualquier persona pudiera visualizarla.

Nuestra solución

Lo primero que hicimos fue extraer la información del caso de uso e identificar los recursos FHIR que podían servirnos para almacenar esta información. En este repositorio GitHub están los archivos JSON, con los recursos que logramos armar. Por temas de tiempo y de las definiciones que nos entregaron para esta situación, hubo varios que finalmente no utilizamos.

Una vez guardados los datos en el servidor, siguiendo las definiciones del estándar, llegó el momento de construir la aplicación.

Nuestro diseño y planificación inicial tenía 3 partes:

Un buscador, que recibiera el rut del paciente, y que se encargará de ir a “preguntar” al servidor por la información.
Una vista de resumen de paciente, que mostrara los datos traídos de la consulta anterior.
Otra pantalla que tuviese un formulario, para poder crear un paciente, o al menos agregarle un nuevo diagnóstico al paciente existente.

Como suele suceder cuando se crean soluciones tecnológicas, el tiempo no era el suficiente y nos tocó priorizar. Es decir, para armar nuestro MVP (producto mínimo viable, por sus siglas en inglés) tuvimos que preguntarnos cuál de todos estos puntos entregaba más valor y era el más esencial. La respuesta fue: la vista de resumen con los datos del paciente ya guardados. Así que ese fue el objetivo inicial, si nos quedaba más tiempo íbamos a ir por el buscador y luego el formulario.

Por supuesto no nos quedó más tiempo, al finalizar el segundo día, logramos desplegar la aplicación con la vista de resumen del paciente solamente.

Detalles técnicos

Si no entiendes mucho de términos específicos de desarrollo web, puedes saltarte esta sección que podría sonar a chino y pasar a la siguiente sin perderte nada, de todos modos intentaré explicarlos lo más en “humano” posible.

El recurso Patient, que como se puede deducir hace alusión al paciente, lo armamos siguiendo las definiciones y ejemplos de la guía para Chile.

Un tip interesante a recordar de la guía core de Chile es que el atributo Address se reemplaza por CL Address, que es igual, pero incluye extensiones obligatorias (city, district, state y country que para nosotros sería: comuna, provincia, región y país respectivamente).

La idea del ejercicio era que también utilizáramos el recurso Bundle, que en resumen permite agrupar y crear al mismo tiempo varios recursos relacionados en este caso con el mismo paciente, es por eso que en el detalle se puede ver que contiene varios recursos Condition, que son los diagnósticos del paciente.

Una vez creado este Bundle, que como ya comentamos en el post anterior, nos demandó más tiempo del planificado, porque no lográbamos que el servidor aceptara la información. Llego el momento de construir la aplicación.

Para desarrollar, por temas de velocidad y conocimiento de ambos, decidimos utilizar el framework de desarrollo fron-end React y le pusimos un poquito de estilo con la librería de interfaz de usuario Ant Design.

Para realizar el despliegue utilizamos 2 herramientas de AWS:

AWS Amplify, para hostear la aplicación.
AWS CodeCommit, que nos permitía desplegar cambios con solo hacer push a la rama main.

Cuando desplegamos la aplicación realizando la consulta por los datos del paciente al servidor FHIR, nos encontramos con un problema importante de seguridad, la aplicación desplegada en Amplify no admitía realizar una consulta a un servidor que no fuera https, y el que nos entregaron para trabajar solo funcionaba con http 😞.

Googleando, logramos encontrar librerías que hacían de proxy para forzar este tipo de llamadas, pero ninguna nos funcionó. Luego Nico dio con el código open source de una (cors-anywhere) y levantó su propio proxy que si dio resultado 🎉 (todo esto último lo hicimos en unos 20 minutos 😅).

Datathon

El desafío durante la Datathon (días 3 y 4)

El tercer día comenzó el evento Make Health y con este la Datathon. El día inició un poco confuso para nosotros, ya que por llegar “heredados” de la Connectathon ni siquiera tenían registro de nuestros nombres en la entrada 😂.

Una vez ingresamos, similar al primer día, tuvimos un par de charlas que se extendieron hasta bastante avanzada la tarde, así que comenzamos a revisar la información para trabajar cerca del final del día.

En este caso se nos disponibilizaron datos del Registro Hospitalario de Tumores de la FALP (Fundación Arturo López Pérez), la idea era que utilizando herramientas de AWS lográsemos trabajar con esos datos, analizarlos y quizás lograr crear un modelo predictivo.

Nuevamente, tal como se planteó en el desafío anterior, se debía crear una aplicación que pudiese interactuar de alguna manera con todos estos datos trabajados.

La solución

La primera alternativa era limpiar los datos, analizarlos y buscar una forma de que estos datos “ordenaditos” se mostraran de una forma amigable para un usuario, por ejemplo, del ámbito clínico. No nos gustó mucho la idea, porque queríamos jugar más con las herramientas de AWS (no todos los días se puede acceder gratis a estas cosas).

Otra opción, y con esta alternativa podíamos utilizar más los conocimientos de Nico en Data Science, fue intentar hacer un modelo predictivo que se entrenara con los datos que nos entregaron. Para esto me puse estudiosa, a tratar de refrescar los conocimientos adquiridos en fisiopatología y epidemiología, para intentar buscar una predicción que pudiese resultar de valor. Una idea loca que surgió fue intentar predecir la sobrevida de un paciente con cáncer según la etapa en la que se diagnóstica y el tipo de tratamiento que recibe, era un tema interesante, pero requería más tiempo.

Así que finalmente nos decidimos por algo un poco más simple, y que más que nada sirviera de prueba de concepto de las herramientas que estábamos probando. Por lo que decidimos crear un formulario que recibiera cierta información demográfica del paciente e información del cáncer diagnosticado, y que predijera el estadio de este cáncer. (Para recordar todo esto de las etapas y el estadio me sirvió mucho, entre otra documentación, esta página: cancer.org).

Detalles técnicos

En este desafío para poder llegar a tiempo nos tocó dividirnos según experiencia y conocimiento, así que, por un lado, Nico se dedicó a construir el modelo predictivo y por mi parte, armé la aplicación con el formulario de ingreso de datos.

Con respecto al modelo predictivo, no partimos de cero. Los datos entregados por la FALP no eran solo bases de datos, sino que también incluían instrucciones de limpieza y de exploración. Por ejemplo, había archivos (Jupyter Notebooks) donde analizaban los datos:

También incluía una descripción del Dataset:

Y código para limpiar:

A base de todo lo anterior, pudimos notar que el problema es de clasificación, en donde dado ciertos atributos demográficos del paciente como género, edad y comuna, hay que predecir en qué estadio de cáncer se encuentra.

Para continuar con la creación del modelo, seguimos los siguientes pasos:

Análisis de los datos: el conjunto de datos era un CSV con 19.000 filas y 23 columnas. Los archivos que nos entregaron incluían una pequeña exploración, donde indicaba la cantidad de pacientes, distribución según género, entre otros aspectos. Nos quedamos con este análisis por temas de tiempo, aunque nos hubiese encantado hacer uno más profundo.
Limpieza de los datos: el dataset venía con instrucciones para limpieza e incluso código en Python, así que no fue tan complicado limpiarlos. Nos quedamos con 2.346 filas, y varias columnas menos. Por ejemplo, no usamos información del tratamiento, ya que esto es algo que ocurre después de la clasificación de estadio.
El modelo predictivo: aquí usamos dos herramientas de Amazon. Una fue SageMaker Canvas y la otra SageMaker Autopilot. SageMaker Canvas fue un primer acercamiento, en menos de 15 minutos nos creó un modelo con 89% de precisión y nos decía qué atributos eran más importantes. Lo malo es que no encontramos una opción para poder usarlo fuera de la herramienta. Así que nos cambiamos a SageMaker Autopilot, que demoraba más en entrenar (~40 minutos) pero nos dejaba un modelo disponible para ser usado.
La puesta en marcha del modelo: Elegimos el mejor modelo sugerido por SageMaker según la precisión (no encontramos cómo cambiar la métrica), y con 1 clic lo pusimos en ejecución.
Disponibilizando el modelo para la web: Gracias a la sugerencia de los “amigos de Amazon” (mentores), logramos hacer que el modelo estuviera disponible a través de internet. Esto lo hicimos con una función Lambda (código fuente), que respondía a eventos HTTP y que se comunicaba con el modelo creado con SageMaker.

De esta imagen, podemos ver que el input consiste en 15 columnas, y que el resultado fue 88.7 precisión, con PT, categoría y sub-categoría como campos más importantes. Posiblemente hay cosas por mejorar, como por ejemplo, el par comuna y región quizás no es necesario, ya que la región se infiere de la comuna. Es posible que pase lo mismo con el par categoría y sub-categoría.

Gracias a lo anterior, ya podíamos hacer solicitudes HTTP para hacer predicciones. Por ejemplo, con Postman:

En cuanto a la aplicación, tal como la anterior, la construimos en React y utilizamos para la interfaz de usuario Ant Design. Los campos disponibles en el formulario eran:

Edad
Sexo
Región de residencia
Categoría del cáncer
Subcategoría del cáncer
Categoría TNM clínica (Tumor-Nódulo-Metástasis)
Categoría TNM patólogica (Tumor-Nódulo-Metástasis)

Le puse cariño en la construcción del formulario para que además de verse decente mostrara las diferentes alternativas de forma bonita para el usuario, aunque “por detrás” mapeaba cada respuesta a cómo el modelo esperaba recibirlas. Esto lo hice creando “diccionarios” en formato JSON, que se encargaban de transformar cada respuesta.

Ejemplo del cómo se transformaban las regiones:

La parte que requirió más detalle fue lograr clasificar las sub-categorías, de tal manera de que una vez seleccionada la categoría principal, solo le permitiera al usuario seleccionar las sub-categorías correspondientes.

Ejemplo del cómo se agrupaban las sub-categorías dentro de cada categoría:

Para terminar, conectamos esta aplicación con el endpoint que Nico había generado. Es decir, envíabamos los datos recogidos por el formulario a ese endpoint, para que estos fueran procesados por el modelo y este nos entregara como respuesta el estadio del cáncer. Finalmente, la aplicación le mostraba al usuario este resultado.

El siguiente GIF muestra el resultado final:

¿Qué ganamos?

El honor y la gloria de ganar un evento como estos ⚔️, junto a un iPad y un curso para cada uno para seguir aprendiendo sobre HL7 🤓.

Impresiones generales

Como conclusiones finales de estos agotadores, pero gratificantes 4 días de trabajo, podemos decir que fue emocionante ver a tanta gente reunida en la misma sintonía, buscando cada uno desde su lugar impactar en mejorar la salud con el apoyo de la tecnología. Como enfermera, cuando estaba en el mundo clínico me tocaba ver estos conceptos como algo totalmente lejano, y es esperanzador ver que hoy ya son una realidad.

Por eso este tipo de instancias, con espacio para ir a escuchar, pero también para participar activamente y “ensuciarse” las manos, permite no solo aprender, sino que también compartir el conocimiento y las experiencias, de sea cual sea el rol que tienes en la salud (profesional clínico, informático, paciente, familiar).

Un aspecto súper positivo fue el apoyo que se consiguió de AWS, ya que no solo nos facilitaron cuentas para utilizar gratis sus diferentes herramientas durante el periodo del evento, también estaban los “amigos Amazon” como los llamamos con Nico, monitores que nos enseñaron en simples pasos a usar las herramientas y nos resolvían cualquier duda que tuviésemos sobre ellas.

En cuanto a las herramientas de AWS, nos llevamos una grata sorpresa. Amplify se ve muy robusto para crear aplicaciones, mientras que las herramientas de SageMaker nos facilitaron mucho la vida a la hora de crear el modelo predictivo, nos resultó infinitamente más sencillo que haber creado nosotros mismos los modelos.

Nos hubiese encantado participar de todas las instancias, las charlas, los paneles, el espacio de la innovación, pero estábamos sumergidos en intentar hacer lo mejor posible en el track que elegimos. Así que ahora nos queda la tarea de ver las grabaciones.

Como en cualquier situación de la vida, hubo cosas mejorables, pero lo más importante fue que los organizadores lograron hacer esto realidad. Había momentos en que estuvimos súper perdidos sin saber cómo continuar, y qué debíamos entregar, pero con Nico nos reíamos pensando en que por algo se llamaba “Emprendethon”, cuando emprendes todo es medio incierto, no necesariamente sabes lo que tienes que hacer, y así estábamos nosotros.

Sentimos que logramos el objetivo, partimos intentando plasmar cómo se recogen los datos ingresados por un usuario, se guardan estandarizados y luego se consultan para su uso primario. Después, continuamos con lo que se puede hacer si esos datos se procesan y se utilizan para crear herramientas que aporten en cierta forma a mejorar algún aspecto de la salud.

Nuestra experiencia en la Connectathon 2023

Nicolás Gómez — Wed, 11 Jan 2023 11:00:00 GMT

Año 2020. Con Eli comenzamos a escribir el “Blog de Nessy”. Para uno de los primeros artículos, ella armó un diseño en Canva para el Blog sobre interoperabilidad.

Casi 3 años después, ese mismo diseño aparece en una de las diapositivas de la “Connectathon”, evento sobre interoperabilidad en salud. Este detalle solo lo notamos nosotros, no tenemos ni idea cómo llegó ahí. Pero es una anécdota que nos hizo partir el evento con mucha motivación 💪

Si participaste en la organización del evento, ¡Muchas gracias! La pasamos muy bien, aprendimos mucho y conocimos a más personas con intereses similares.

Nota: nosotros participamos en el track de “Emprendethon”, así que las observaciones y comentarios serán como asistentes a esa experiencia, que puede ser diferente al resto.

Nuestras impresiones del evento “Connectathon”

¿Qué es la Connectathon? Es un evento que reúne a decenas de proveedores y emprendedores del mundo clínico en un periodo de varios días, los que variaran según el organizador. En el transcurso de este evento, son puestas a prueba en la práctica las funcionalidades de interoperabilidad de los diferentes sistemas — Fuente

No sé tú, pero muchas veces en la vida me han recomendado series o películas que terminaron siendo menos de lo que esperaba. Creo que las expectativas previas que tienes sobre acontecimientos son también parte del evento en sí.

En este caso, nos preparamos para poder estar la semana completa. Eli, que trabaja para Continuum, asistió como representante de la vertical salud, para poder adquirir conocimientos importantes tanto para ella como para la empresa (uno de los muchos beneficios de trabajar en un lugar centrado en las personas), así que debió gestionar con su equipo como se continuaría avanzando en su ausencia. Por mi lado, trabajo independiente, así que adelanté trabajo las semanas previas para tener la semana disponible.

Para la estadía, coordinamos con mi mamá, que tiene una cabañita en Laguna Verde, y así estar más “cerca” del sitio del evento. Hace años que no me despertaba antes de las 7 am para trabajar 😂, además resulta toda una experiencia trasladarse 1 hora con computadores y pendones en las veloces micros de Valparaíso.

Imagina lo enojado que estaría si el evento no hubiese cumplido mis expectativas 😅. La verdad es que me ha gustado mucho el evento, y definitivamente volvería a ir para ediciones futuras.

Siendo un poco más concreto, estas son mis observaciones:

Programa: el programa del evento fue compartido con nosotros con anticipación. Entonces, en todo momento, sabíamos más o menos qué cosas venía. O el menos Eli. Yo soy de esos que no leen las instrucciones en los juegos (y, aun así, no me perdí… creo). El track de Emprendethon estuvo extraño: partió muy básico, pero finalizó con alta complejidad.
Logística: siento que hubo más coffee breaks de lo planeado, lo cual es bueno 😂. Esto no afectó las actividades planificadas, ya que todos los días terminamos a la hora y tuvimos tiempo suficiente para realizar las actividades.
Servicios: coffee break un 7. Los jóvenes que nos registraban también, eran muy atentos. Además, siempre estaba todo muy limpio, el personal de aseo higienizaba con mucha frecuencia.
Ambiente: se sentía mucha buena onda y motivación. Vi muchas personas saltándose los coffee breaks para poder seguir programando, ¿quién hace eso?. También fue genial ver personas de las que he aprendido tanto, como miembros del capítulo de HL7 y profesores del CENS.
Aprendizaje: fue una grata sorpresa tener una pincelada de algunos de los servicios de AWS. Por el lado de FHIR, si bien teníamos cierta experiencia con FHIR, no habíamos interactuado con un servidor que implementara los perfiles del Core de Chile. En consecuencia, tuvimos que seguir las guías de implementación (esto sí que lo leí 😅) y sufrimos con el caso de uso de la Emprendethon. Aquí la culpa es compartida: algunos aspectos técnicos del servidor no funcionaban bien, detalles del enunciado ambiguos y cosas que nosotros no manejábamos.

Nuestros puntos de frustración durante la Emprendethon

El track de Emprendethon tenía dos componentes:

Utilizar el estándar HL7 FHIR para registrar información de un paciente, una organización, un profesional y algunos diagnósticos.
Construir una pequeña aplicación desplegada con AWS Amplify que consumiera estos datos.

Me gustaría comentar puntos de “dolor” que tuvimos al desarrollar estos dos componentes:

Las charlas iniciales del “Emprendethon” eran introductorias, al contrario de lo que entendimos de la descripción del track. Llegamos a pensar que deberíamos haber ido a otro, hasta que llegamos a la parte práctica, donde el caso de uso se volvió más complejo de lo que pensamos.
No había instrucciones muy claras respecto a lo que debíamos hacer técnicamente hablando. Teníamos que crear un recurso FHIR Bundle, pero no había claridad del tipo. Asumimos por un taller previo de historia clínica que debíamos usar un “document” enviando un “composition”. Cuando nos dijeron que no iba el composition, cambiamos a tipo “collection”, pero ninguna de estas opciones eran aceptadas por el servidor. Las instrucciones verbales fueron confusas, y finalmente, luego de ensayo de error y con la bendición de nuestro guía, usamos el tipo “transaction”.
Todo lo anterior hizo que se nos fuera mucho tiempo entendiendo el alcance del proyecto, sus restricciones y los parámetros con los cuales nos evaluarían. Por lo mismo, gastamos mucho tiempo intentando modelar todo el caso de uso con recursos FHIR, hasta que nos dijeron que utilizáramos solo un subconjunto de toda la información.
El servidor FHIR que usamos tenía ciertos problemas técnicos. El día 1, los pacientes de ejemplo del Core no pasaban la validación ($validate). Eso hizo que nos preguntáramos si estábamos haciendo algo mal o si era problema del servidor.
El servidor FHIR que nos disponibilizar usa HTTP, mientras que AWS Amplify fuerza HTTPS. Eso significa que la aplicación que subiéramos no iba a funcionar por un error de seguridad. Nos dimos cuenta al final, cuando quedaban 15 minutos.
En la presentación final mostraron estadísticas de creación de recursos para nuestro track, las cuales estaban desactualizadas. Logramos crear al menos 4 recursos de “Condition” (se dijo que fueron 0 entre todos los grupos), pero al mismo tiempo, mostraron capturas de pantallas de dos aplicaciones que los rescataban (entre esas, una era la nuestra 🙌).

Esto no es un reclamo, simplemente fueron las cosas que nos costaron o frustraron. En este tipo de actividades siempre estamos expuestos a este tipo de situaciones, así que estábamos mentalizados. Por ejemplo, logramos “solucionar” el problema número 5 utilizando un “proxy” (con Heroku, eso sí, estábamos apurados).

Nota: tenemos cierta experiencia con el estándar, nos sabemos mover por la documentación y sabemos hacer las consultas.

El resultado de nuestra participación en estos dos días

Analizando el resultado concreto, nos fue bastante bien. Logramos crear los recursos FHIR correspondientes (Patient, Organization, Practitioner, Condition), creamos una mini aplicación que mostraba la información del paciente obteniéndola desde el servidor, y también pudimos desplegarla en AWS Amplify.

Gracias a esto, mostraron una captura de nuestra web en la presentación final 🎉 Sin embargo, nos fuimos con un sabor un poco amargo, teníamos expectativas personales mayores. Queríamos hacer un frontend mucho más bonito y con más funcionalidades, pero al menos cumplimos con el MVP 😂

Captura de nuestra aplicación, el equipo Co-Co 🥥 (Continuum + Codeness).

Ahora estamos preparándonos para los próximos 3 días. Seguiremos en el track Emprendethon, ahora acogidos por la Datathon. No sabemos qué nos espera, sin embargo, seguiremos con la motivación para continuar aprendiendo 🤓.

¿Cómo montar un servidor FHIR en Google Cloud?

Nicolás Gómez — Thu, 06 Oct 2022 14:00:00 GMT

Como desarrollador de software en salud, hace tiempo le eché un ojo a Cloud Healthcare API de Google, que según la página te permite almacenar y gestionar datos en formato FHIR.

Al fin me di el tiempo de hacer una pequeña prueba. Aquí está el paso a paso, de manera de que tú también puedas hacerlo.

Requisitos

Este artículo es algo técnico. Si bien la creación de la instancia FHIR es mediante la interfaz de Google, si quieres probar agregando recursos (por ejemplo, un paciente), tendrás que ejecutar ciertos comandos.

Para crear el recurso, necesitarás usar Postman, así que tenlo instalado si aún no lo haces.

Nota: Postman es una aplicación que te permite interactuar con APIs. Es una manera sencilla de hacerlo, ya que no necesitas escribir comandos en la consola. Todo lo haces mediante una interfaz gráfica.

Paso a Paso para tener tu servidor FHIR andando

1) Activar tu cuenta en Google Cloud

Nota: si ya has usado Google Cloud, este paso no es necesario.

Lo primero que tienes que hacer es entrar a https://console.cloud.google.com para activar tu cuenta en Google Cloud.

Aquí tendrás que aceptar las condiciones, y con esto estás OK.

2) Crear un proyecto en Google Cloud

Nota: si ya tienes un proyecto donde quieres montar tu servidor FHIR, no necesitas crear uno nuevo.

Tienes que crear un proyecto, y debes colocarle un nombre que represente tu proyecto.

Una vez creado, te llevará a un panel con mucha información:

3) Habilitar Cloud Healthcare API

Google Cloud Platform es un producto de Google… Así que la forma más fácil de navegar por la herramienta es usando el buscador.

Arriba, en la barra de search, coloca “healthcare”, debería salirte algo así:

Selecciona la primera opción, que dice “Healthcare data storage and processing”, lo cual te llevará a la siguiente pantalla:

Y ahí le das clic a “ENABLE” (o habilitar).

4) Habilitar Billing

Es probable que te aparezca el siguiente mensaje:

Así que tienes que habilitar el “Billing” en tu proyecto. Lo bueno es que te dan 300 USD en créditos gratuitos que podrás usar en los próximos 90 días.

Lo malo es que igual necesitas colocar una tarjeta de crédito.

Sin embargo, esta prueba no te consumirá recursos para que tengas que pagar de tu bolsillo.

5) Crear tu instancia FHIR

Nota: en adelante, me cambié de cuenta para no activar los créditos gratuitos. Así que ahora el proyecto se llama “apposito-Dev” y no “nessy-fhir-test”

Ahora tenemos todo lo necesario para crear una instancia FHIR. Puedes ver la guía oficial, que está bien explicada para más detalles.

Te voy a explicar con mis palabras lo que vamos a hacer a continuación:

Crear un “Dataset” (conjunto de datos). Un Dataset es un conjunto de datos donde vivirán tus instancias de FHIR. Dependiendo del proyecto, puede que necesites tener más de un servidor FHIR, y esta es una manera de agruparlos.
Crear un “Datastore”. Un Datastore es un almacén de datos, y corresponderá a tu instancia FHIR.

En otras palabras, para crear una instancia de FHIR (almacén de datos, Datastore), necesitas colocarlo dentro de un conjunto de datos (Dataset). Así que…

Lo primero que tienes que hacer es crear un dataset:

Tienes que elegir un nombre y una región. Yo le colocaré “test”, y lo crearé en “us-east1”:

Luego de esperar un momento (1 minuto?), tu “Data Set” estará listo.

Puedes acceder a tu Dataset, donde verás la opción de crear un “Data Store”:

El formulario es guiado, ahí puedes ir seleccionando las opciones que estimes convenientes. Para este ejemplo, a mi instancia FHIR le coloqué como nombre “test”, de tipo “FHIR”, y en “R4” (la guía de implementación de Core-CL está en FHIR R4):

Nota: Las opciones de BigQuery y de Cloud Pub/Sub por ahora puedes omitirlas.

Le das clic a crear y listo, tendrás tu instancia FHIR creada:

Si le das clic, podrás ver más información de tu almacén FHIR:

Lo más importante de aquí es el “path”, ya que lo usarás para poder hacer operaciones FHIR.

Crear un paciente de prueba (usando Postman)

Tu instancia de FHIR ya está OK. Ahora veremos como realizar una operación FHIR en el almacén que acabamos de crear.

De todo este tutorial, esto fue lo que más me costó. Por alguna razón, no podía autenticarme de manera correcta. Ahora te diré cómo hacerlo de manera fácil.

1) Obtener token de autenticación

Para crear un recurso en tu almacén FHIR (por ejemplo, un paciente), necesitas autenticar la operación que vas a realizar. Esto en términos técnicos, es agregar un token de autenticación en el header de tu solicitud HTTP.

Para obtener el token, lo más fácil es hacer lo siguiente. Hay un ícono al lado derecho del buscador:

Es como un “>_”, que dice “Activate Cloud Shell”. Le das clic, y te abrirá un Terminal dentro de tu browser:

Ahora, en la consola, ejecuta el siguiente comando:

gcloud auth application-default print-access-token

Te aparecerá una ventana que dice que la terminal te está solicitando datos, le das aceptar y deberías ver un texto:

Copia ese texto (que es el token), lo necesitarás en el siguiente paso.

2) Crear un Request

En Postman, crea un nuevo HTTP Request:

Como vamos a crear un recurso, tienes que seleccionar POST.

3) Agregar autenticación

En la sección Headers agrega uno que se llame Authorization y en el valor, coloca Bearer <tu token>:

4) Armar la URL base de tu servidor FHIR

La URL base de tu servidor FHIR es algo así: https://healthcare.googleapis.com/v1/{path}/fhir.

¿Recuerdas que te dije que el path era importante? (cuando creaste tu almacén de datos FHIR), bueno, ahora vamos a usarlo.

En mi caso, el path es: projects/apposito-dev/locations/us-east1/datasets/Test/fhirStores/test

Reemplaza en la URL que coloqué arriba donde dice {path} por el PATH de tu almacén, y tendrás como resultado la URL base de tu servidor FHIR. En mi caso:

https://healthcare.googleapis.com/v1/projects/apposito-dev/locations/us-east1/datasets/Test/fhirStores/test/fhir

Nota: no olvidar colocar al final /fhir.

5) Enviar solicitud

Para interactuar con un recurso en FHIR, tenemos que hacerlo mediante la URL del recurso, la cual es Base + /Recurso.

Base es la URL base del servidor FHIR (paso anterior), y el recurso que usaremos ahora es Patient.

En mi caso, la URL para interactuar con Patient es:

https://healthcare.googleapis.com/v1/projects/apposito-dev/locations/us-east1/datasets/Test/fhirStores/test/fhir/Patient

Y esa URL hay que colocarla en Postman:

Finalmente, en el “body” de la solicitud, debemos colocar los datos de paciente:

{
    "name": [
        {
            "use": "official",
            "family": "Smith",
            "given": [
                "Darcy"
            ]
        }
    ],
    "gender": "female",
    "birthDate": "1970-01-01",
    "resourceType": "Patient"
}

Eso en Postman, va dentro de “body”, seleccionar “raw” y luego “JSON”:

Y le damos clic a “Send”. Si todo salió bien, deberías ver como Response a tu paciente:

Visualizar tus recursos con FHIR viewer

Ahora que ya creaste tu recurso Patient, puedes usar la misma interfaz de Google Cloud para ver la información.

En Google Cloud, haces clic en FHIR viewer:

Seleccionas tu almacén FHIR, y verás un listado de recursos. Buscas el recurso Patient, le das clic y podrás ver los datos de prueba que ingresaste:

Palabras finales

Montar un servidor FHIR con Google no es tan complejo. De hecho, toda la creación se hace mediante la interfaz de Google, sin necesidad de escribir código.

La interacción con el servidor es un poco más complicado. Por un lado, debes saber como realizar operaciones FHIR, como autenticar tus solicitudes y descubrir cuál es la URL de tu servidor FHIR para poder enviar solicitudes.

Sin embargo, la herramienta FHIR viewer permite ver los recursos que has ingresado, con toda la información e incluso permite hacer búsquedas. Todo esto mediante la misma interfaz, sin código.

Lo bueno de usar Google Cloud es que permite conectarte con otras herramientas de manera “nativa”. De hecho, una siguiente prueba que quiero hacer es insertar datos de FHIR a partir de Firestore.

Herramientas digitales para emprendedores

Nicolás Gómez — Thu, 15 Sep 2022 19:00:00 GMT

En los últimos años, el mundo ha tenido un crecimiento acelerado en cuanto a adopción de tecnología, tanto por empresas como por las mismas personas.

Latinoamérica no se queda atrás. La pandemia trajo muchos cambios culturales relacionados con internet. Las cuarentenas hicieron que muchas personas comenzaran a utilizar aplicaciones como WhatsApp para mantener contacto con sus familiares. Además, comenzó a ser más común comprar en línea, donde muchos superaron el miedo de sacar la tarjeta para pagar.

Es por eso que es clave tener presencial digital, aunque tu negocio no lo sea. Incluso si no te interesa tener un canal de marketing digital, puedes aprovechar el boom de tecnología para mejorar ciertos aspectos de tu emprendimiento. Quizás hay algunos procesos que puedes optimizar con tecnología.

El tren de la digitalización partió hace muchos años, pero ahora ha estado acelerando. ¿Te subes? Aquí te presentaré algunas herramientas que te pueden ayudar a digitalizar tu emprendimiento o parte de él, de manera de que puedas hacer más con menos.

Redes Sociales

Las redes sociales puedes usarlas para dar a conocer tus productos y para generar confianza con posibles clientes. No es necesario utilizar TODAS las redes sociales al mismo tiempo.

Las redes sociales más populares son, junto al grupo etario más activo (estadísticas obtenidas aquí):

Instagram: 25-34 (31.2%), con 18-24 muy cerca (31%)
LinkedIn: 25-34 (58.4%)
Facebook: 25-34 (31.5%)
YouTube: 15-35 (mayor alcance)
Twitter: 18-29 (42%)
TikTok: 10-19 (25%)

¿Cuál usar? Diría que la que se adapte más a tu público objetivo (¿cuál es la que más usan tus clientes, y para qué las usan?).

Sugerencia: los grupos de Facebook son un buen lugar para ver a personas de tu nicho interactuando en vivo. Por ejemplo, si vendes productos para “mamás cuidadoras”, de seguro encontrarás un grupo en Facebook de mamás cuidadoras. Puedes hacerte parte de él y hacer un poco de netnografía: ¿qué productos recomendan? ¿qué problemas tienen? ¿qué palabras usan? ¿que visión del mundo tienen?. Creo que es una verdadera mina de hora si te das el tiempo de investigar.

Herramientas de automatización de redes sociales

Si eres como yo, prefieres estar una mañana creando publicaciones para un mes completo, que estar todos los días subiendo contenido.

Existen herramientas donde puedes dejar publicaciones programadas, de manera de que aunque las crees a las 12 de la noche, tus seguidores la verán a las 8 del día siguiente (o a la hora que tú quieras).

Algunas de estas son:

Ambas tienen para agendar contenido en prácticamente todas las redes sociales.

Hay otras herramientas donde además de agendamiento, te sugieren publicaciones que se han hecho viral a modo de inspiración. Estas son:

Taplio para LinkedIn.
Tweethunter para Twitter.

Sin embargo, estas dos funcionan bien para escribir en inglés.

Páginas web

Ya con tus redes sociales andando, lo siguiente es tener una página web donde puedan leer más sobre tus servicios o productos.

Para crear una página no necesitas tener un programador. Y si tienes más tiempo que dinero, quizás puedes armarla tú.

Existen distintos servicios que te permiten crear una página sin saber programar, alguno de ellos:

bio.link: esta es una página donde muestras enlaces relevantes. Por ejemplo, puedes colocar links de tus productos, link a otras redes sociales, etc.
carrd.io: te permite armar un sitio de una sola página. Perfecto para landing pages, lead magnets, páginas de venta, entre otros.
webflow.io: te sirve para armar un sitio con muchas páginas, que tenga productos, blog y otro tipo de contenido generado. Es más caro que las opciones anteriores, pero a la vez mucho más poderoso.
shopify: te sirve para armar una tienda online (“ecommerce”) para que vendas tus productos.
salduu: para vender contenido digital (como cursos, ebooks, pdfs, etc).

Investigación de Mercado

¿Cuáles son las últimas tendencias? ¿Qué nicho te conviene servir? ¿Cuáles son los problemas que tu audiencia o nicho tienen? ¿Qué está haciendo tu competencia?

Una forma de resolver estas dudas es investigando. Hay algunas herramientas que te pueden ayudar:

Google Keyword Planner: Te ayuda a saber qué es lo que la gente está buscando en Google, qué tanto volumen hay y búsquedas relacionadas
SimilarWeb.com: te permite ver el posicionamiento de una página web en internet (tráfico mensual, de qué países, distribución por edad, competidores y sitios similares).
Facebook Groups: puedes hacer “netnografía” para ver qué hacen, que piensan, qué recomiendan. De seguro hay un grupo en tu nicho de mercado.
Tally Forms: te permite crear formularios web sin código y de una manera muy amigable. Un formulario web te puede servir para solicitar información a tus clientes, recoger reviews, hacer encuestas, etc.

Herramientas para productividad

Estas herramientas te ayudan a ahorrar tiempo en tareas o cuando trabajas en equipo.

Google Workspace: Solución de Google para trabajo en equipo. Incluye muchas herramientas: Email (Gmail con correo corporativo), Calendario (compartido), archivos compartidos (Google Drive). Alternativa: Notion.so
Calendly: Si quieres tener reuniones con posibles clientes o con tu equipo, puedes enviar tu disponibilidad para que ellos tomen una reunión contigo en tus horas disponibles.
ClickUp: Herramienta para planificar y llevar seguimiento de tareas. Muy útil para saber en qué está cada miembro de un equipo. Alternativas: Asana, Monday, Trello, Basecamp
Loom: en vez de tener reuniones, puedes grabar un video explicando algo mientras compartes tu pantalla.

Email Marketing

Las redes sociales son geniales, pero no te dan una forma directa de contactar a tu audiencia. Además, si te cierran la cuenta, pierdes todos los contactos…

En cambio, si armas una lista de correo electrónico, puedes contactarlos de manera directa. Puedes compartir contenido de valor, generar conversaciones interesantes y eventualmente ofrecer productos y servicios, todo directo en la casilla de tus suscriptores. Además, es posible armar automatizaciones para que todo esto ocurra de manera automática.

Hay muchos software que te permiten armar una lista de correos, lo que he usado son los siguientes:

Mailchimp: Plataforma de Marketing por correo orientada en todo tipo de negocio, desde creadores de contenido hasta tiendas online.
Convertkit: Herramienta de Marketing por correo orientada a creadores de contenido.

Ambas herramientas permiten automatización, segmentación de suscriptores, creación de páginas web para adquirir más suscriptores, etc.

Cosas interesantes que puedes hacer: si un usuario intentó comprar pero se arrepintió, le mandas un descuento (con fecha de expiración) a su correo para concretar la venta.

Comunicación con tu equipo

Cuando ya tienes un equipo, se hace una necesidad tener un canal de comunicación digital. Algunas herramientas:

WhatsApp: Puedes usar WhatsApp para comunicarte con tu equipo de trabajo y colaboradores.
Slack: Es como un WhatsApp, pero donde la información la puedes tener mucho más ordenada. Por ejemplo, puedes organizar tu chat por canales. Además permite integración con otras herramientas. Por ejemplo, puedes tener un canal donde luego de cada venta en Shopify te llega un mensaje de celebración.
Discord: El Chat de los jóvenes. Si tienes un equipo de trabajo jóven, de seguro conocen Discord. Te permite tener las conversaciones ordenadas, tener video llamadas, etc. Lo mejor de todo es que el plan gratuito es muy permisivo.
Zoom: para tener videollamadas.

Atención al cliente

¿Qué pasa si tienes que ofrecer un canal de soporte? Quizás puedes ofrecer un chat directo contigo. Entre las opciones están:

ManyChat: Te permite tener chat con tus prospectos o clientes. Además puedes automatizar con bots.
WhatsApp: Puedes colocar un “click para chatear”, y cuando una persona lo presiona, te lleva directamente a una conversación contigo. El enlace tiene este formato: https://wa.me/1XXXXXXXXXX, donde reemplazas el número al final por el tuyo.
Intercom: Herramienta avanzada para comunicación con tus clientes y soporte. Es un todo en uno: Chat, email y centro de ayuda. Alternativa: crisp.

Analítica web

¿Cuáles son las páginas más visitadas en tu sitio? ¿De qué país son tus visitantes? ¿Cómo encontraron tu página?

Para responder estas preguntas, necesitas tener instalado en tu página web una herramienta de analítica:

Google Analytics: es uno de lo más usados, además tiene integración con Google Ads y con otras herramientas de Google. Es gratis, aunque pagas con la privacidad de tus visitantes.
Fathom Analytics: una alternativa a Google Analytics que respeta la privacidad de tus clientes.

Todas estas herramientas son de fácil integración.

Testimonios (boca a boca)

Uno de los mejores motores de crecimiento es el boca a boca. Existen algunas herramientas que te ayudan a obtener estos “testimonios” de tus clientes:

Google Business: Puedes agregar tu empresa en “Google Business” de manera de que aparezca en Google Maps. Luego con eso en mano, tus clientes pueden agregar testimonios (“Reviews”).
Testimonial.to: Te permite recoger y mostrar testimonios de tus clientes (texto y video). Los testimonios los puedes agregar luego a tu página web. Alternativa: senja.io.

Diseño

Mi herramienta favorita de diseño es lejos Canva. Te permite crear contenido visual para múltiples propósito, desde logos hasta presentaciones. Incluso ahora han agregado opción para diseñar páginas web…

Palabras finales

Como puedes ver, hay muchas herramientas digitales que nos hacen la vida más fácil. La mayoría no requieren tener a alguien experto en informática, y si se usan bien, puedes incrementar tus ventas, desminuir costos y tener más tiempo libre. ¿Qué mejor?

Mi única sugerencia es que vayas aplicando herramientas de a poco, y que uses la que encuentras más fácil de usar para tu contexto particular. Recuerda que la idea de la herramienta es facilitarnos la vida, no complicarla.

Por qué descontinuamos el Nessy Letter

Nicolás Gómez — Tue, 23 Aug 2022 01:30:00 GMT

Julio 2022 fue el último mes que escribimos el “Nessy Letter”, un newsletter mensual que reúne noticias y artículos que encontramos interesantes sobre salud + informática.

En este artículo voy a escribir las razones por las cuales comenzamos a escribirlo, por qué lo descontinuamos y los aprendizajes del proceso.

Por qué partimos con Nessy Letter

“Darnos a conocer y ver qué pasa en el proceso”

Con Eliana comenzamos a escribir en el Blog de Nessy en noviembre 2020, buscando publicar al menos una vez a la semana.

Nuestro objetivo era darnos a conocer en la vertical de salud, decirle al mundo que estábamos creando cosas, y en el camino entregar contenido de valor. No teníamos nada que vender, ningún servicio que ofrecer. Más bien queríamos compartir contenido y ver qué pasa.

El Nessy Letter tiene un origen parecido. Partimos agregando una sección al blog para que las personas interesadas se suscribieran: “Nessy Letter — Boletín sobre informática en salud. Compartiremos a tu correo todo lo que estamos aprendiendo de este mundo.”

La propuesta de valor es vaga, del estilo “Suscríbete para más”. Eso es porque solo queríamos ver qué pasaba si agregábamos la cajita.

Luego de ver que habían personas que se registraban pensamos: ¿qué pasa si compartimos mensualmente lo que vamos aprendiendo? Y así nació Nessy Letter.

Los resultados iniciales

En el periodo que estuvimos activos publicando en el blog y compartiendo en LinkedIn (noviembre 2020 - febrero 2021) de 582 visitantes, se suscribieron 7 personas. Ahí fue cuando decidimos enviar la primera edición.

Todo lo que puedo decir del resultado inicial fue que nadie se desuscribió 😁. No medimos las aperturas de correos ni los clicks, ya que esas métricas por sí solas (sin un objetivo de negocio por detrás) no vale la pena medirlas. Además, la caja de suscripción dice “respetamos tu privacidad”, y hay que ser consecuentes.

Por otro lado, la acción en sí de escribir el Newsletter me pareció entretenido. Además, me obligaba a tener que estar pendiente de noticias en el área.

Hasta ahí, todo bien.

Lo malo de no tener un objetivo muy claro desde el principio

Pasaron 18 ediciones para decir stop: “¿por qué estamos haciendo esto?”

Por un lado, creo que la decisión de partir un boletín mensual fue buena. Los Newsletter son una buena forma de compartir conocimiento, aprender y además se prestan para generar conversaciones interesantes.

Por otro lado, los resultados no fueron muy buenos. El origen del blog y del newsletter fue darnos a conocer en la vertical de salud. El blog cumplió su objetivo con creces, mientras que el Newsletter… ni idea.

Eliana consiguió su trabajo actual en gran parte gracias a distintas entradas que fue publicando. Por mi parte, se han contactado conmigo por distintos posts que he escrito, colegas me han recomendado para trabajos de tecnología en salud y posibles clientes me han encontrado por alguna entrada del blog.

Pero nada de lo anterior pasó gracias al Newsletter. Quizás este servicio amplificó el mensaje, pero ¿qué hubiese pasado si el tiempo invertido en el Newsletter lo invertíamos en escribir el Blog?

Parte del problema es no haber tenido un objetivo claro. Ojo no suscribo a la idea de que “si no sabes a dónde vas, no sabrás nunca si has llegado”. Soy más de la liga de hacer algo y ver qué pasa, estar abierto a las posibilidades que una acción te da. Sin embargo, hay que saber cuándo parar.

En este caso, el objetivo podría haber sido “hagamos 8 ediciones y veamos qué pasa”. Pero ni siquiera fue algo que consideramos. Entramos en modo automático y escribimos 18 ediciones 👍

¿Qué pasa si aumentamos la cantidad de lectores?

El Nessy Letter en un año consiguió cerca de 30 suscriptores. Si pocas personas leen, ¿cómo saber su utilidad?

Por eso siempre fui publicando en LinkedIn las distintas ediciones. De esa manera, al menos aumentaba la cantidad de personas que lo leían, o por lo bajo, que sabían que estaba escribiendo sobre la industria (esas publicaciones tuvieron al menos 600 impresiones cada una).

Luego pensé: ¿qué pasa si publico en un Newsletter de LinkedIn? Para inicios de año contaba con unos mil seguidores, entonces no partiría desde cero. Esta fue la forma más sencilla de aumentar los suscriptores que se me ocurrió.

Es por eso que la edición de Febrero 2022 la publiqué con la herramienta de Newsletter de LinkedIn, donde 300 personas se suscribieron y recibieron las siguientes ediciones hasta Julio 2022.

La decisión de no continuar

En mitad de Julio hablé con Eli sobre para qué queríamos seguir escribiendo el Newsletter, y no llegamos a una razón para continuar.

Algunas consideraciones:

Para darnos a conocer, tenemos el blog. Ha demostrado ser mucho más efectivo.
No tenemos un motivo para obligarnos a leer noticias y compartirlas, considerando que hay una inversión de tiempo ahí.
No tenemos una forma de medir el valor generado para la audiencia. Y aunque existiera, no hay valor para nosotros.

Como no llegamos a un buen motivo, decidimos pararlo.

Aprendizajes de haber escrito el Newsletter por más de un año

Te dejo algunos aprendizajes de haber escrito Nessy Letter por más de un año:

Es más difícil de lo que parece. Soy un consumidor de distintos Newsletter, y la verdad es que desde afuera se veía mucho más fácil. El proceso de recolección de noticias toma tiempo, así como también el de redacción. Yo diría que me tomaba al menos 4 horas, sin considerar el tiempo de edición de Eli.
Es una buena forma de obligarte a estar pendiente de las noticias relevantes en tu industria y además te permite darte a conocer sin necesidad de escribir contenido propio (como un blog).
Es difícil saber si estás haciendo las cosas bien. Yo diría que el “boca a boca”, que tu audiencia invite a sus pares o comparta tus ediciones, es un buen indicador. Así como también la cantidad de conversaciones que genera. Open Rate / Click rate son métricas de vanidad que por sí solas no sirven.
Intenta tener un objetivo. El de nosotros fue “darnos a conocer y ver qué pasa”. No es “SMART”, y no tiene por qué serlo. Sin embargo, creo que es clave colocar una limitante de tiempo para ver si se están cumpliendo tus expectativas.

¿Qué son las Healthtech?

Diana Núñez — Fri, 29 Jul 2022 16:00:00 GMT

Healthtech, conocidas también como Health Technology, son una serie de investigaciones relacionadas a la tecnología y la salud; o, mejor dicho, enfocadas en el desarrollo de dispositivos, aplicaciones y sistemas que favorezcan el cuidado personal y la salud de las personas.

Dicho esto, abarcan desde los conocimientos en el sector de la salud y el desarrollo de nuevas medicinas y vacunas, hasta la implementación de novedosos procedimientos y tratamientos que mejoren la atención de las enfermedades y afecciones.

Esta tecnología sanitaria existe desde los inicios de la medicina, ya que cada avance médico requiere de investigaciones tecnológicas que funcionan como sustento para su buen desarrollo. Gracias a ello, Healthtech forma parte de nuestro día a día.

Vertientes principales de Health Technology

Ahora que entendemos mejor lo que son las Healthtech, hablemos un poco sobre los sectores principales de sus investigaciones. En la actualidad, esta tecnología se aplica a todos los sectores de la salud:

Salud mental: Acceso a servicios de salud mental de forma online. (Ej: Yana, Terapify).
Telemedicina: Prestación de servicios de salud virtual por parte de profesionales de medicina general y especializaciones. (Ej: 1Doc3)
Seguros de salud integral: Mejoras en cuanto a la ubicación y elección de los seguros privados. (Ej: QuePlanCl)
Farmacias online: Procesos de compra y obtención de medicamentos de manera remota. (Ej: Farmalisto, Vitau).
Dispositivos médicos: Tecnologías que optimizan el proceso de diagnóstico y prevención de enfermedades. (Ej: Eva, Unima, Whoop, Fitbit, OuraRing).

Con la llegada del Covid-19 al mundo, se hizo necesaria una actualización en cuanto a la atención médica remota, para así evitar la saturación de los centros de salud y la exposición de personas sanas o con otras afecciones a la peligrosa enfermedad.

¿Qué ventajas ofrece Healthtech?

La tecnología sanitaria se basa en mejorar la calidad de vida de las personas; principalmente, al autocuidado de los pacientes, a la adherencia a los tratamientos y a evitar hospitalizaciones, tratamientos y procedimientos innecesarios.

Con cada Health Technology, los sectores de la salud se vuelven más eficientes y los pacientes se ven recompensados con mejoras en la detección oportuna de las enfermedades, así como al olvidarse de las largas listas de espera o de las visitas a la farmacia de turno.

Sin duda, se trata de una oportunidad para avanzar en un campo importante en la vida del ser humano.

Recursos Adicionales

Si te interesa aprender más sobre health tech, te dejo los siguientes recursos:

Apposito — Versión 1.0.28

Nicolás Gómez — Tue, 26 Jul 2022 16:00:00 GMT

¿Qué hay de nuevo?

Desde el punto de vista de usuario, hay 2 funcionalidades nuevas:

1) Desbloquear Pantalla cuenta con opción para reiniciar contraseña

Haciendo pruebas con la aplicación, siempre me pasaba que se me olvidaba la contraseña. Lo cual es malo cuando Apposito se bloquea por inactividad, ya que te quedas encerrado sin poder hacer mucho.

Debido a esto, agregamos 3 mejoras a la pantalla de bloqueo:

Agregamos un cerrar sesión.
El formulario de contraseña incluye la opción de reiniciar contraseña, y además, te muestra un hint del correo con el que iniciaste sesión.

2) Ahora puedes eliminar tu cuenta

Desde el 30 Junio del 2022, si quieres publicar en Apple y tu aplicación ofrece creación de cuenta, es obligatorio ofrecer una opción de eliminar cuenta.

Si bien esta funcionalidad no estaba en nuestro Roadmap, tuvimos que hacerlo debido a esta nueva política de Apple.

Al eliminar tu cuenta, eliminaremos solo tu acceso a Apposito. Los registros que hayas subido no serán eliminados, ya que es información de pacientes.

Si bien solo en iPhone es obligatorio, los usuarios de Android también tendrán habilitada esta opción.

Qué sigue

Estamos trabajando en una actualización para el listado de pacientes, que hará que sea más eficiente en cuentas pertenecientes a una organización.

Dónde descargar Apposito

Apposito está disponible en iPhone y Android. Puedes acceder a la página web de Apposito para más detalles de la aplicación.

¿Qué es HL7 FHIR?

Nicolás Gómez — Mon, 11 Jul 2022 14:00:00 GMT

Partiré con una definición menos formal sobre HL7 FHIR.

Si pensamos en idiomas, sabemos que el inglés es un lenguaje “Universal”. Por ejemplo, si quisieras comunicarte con una persona que solo habla Chino, lo más seguro es te comuniques con ella en Inglés.

Es por eso que saber inglés es importante, ya que te abre puertas para poder comunicarte con el resto del mundo.

En sistemas informáticos pasa algo parecido… Distintos sistemas se pueden comunicar entre ellos, y para hacerlo, se ponen de acuerdo en el “lenguaje” en el cual van a intercambiar información.

En el ámbito de salud, es muy importante que apuntemos como sociedad a que todos los sistemas de salud hablen entre ellos. Y para eso, es necesario que se haga en un lenguaje “común”, algo así como sería el Inglés.

Es aquí donde entra “HL7 FHIR” (o simplemente “FHIR”). El cual es un “lenguaje” único que permite que distintos sistemas informáticos en salud se comuniquen entre ellos. Es decir, “FHIR” es como el “inglés” pero para sistemas informáticos en salud.

Finalmente, cuando dos sistemas informáticos son capaces de intercambiar información entre ellos, decimos que “interoperan” o que son “interoperables”.

Definición formal de HL7 FHIR

FHIR es un estándar para el intercambio de datos de salud. Fue creado por HL7, una organización sin fines de lucro que desarrolla estándares sintácticos desde 1987.

FHIR es el acrónimo de Fast, Healthcare, Interoperability, Resources, lo que significa:

Fast: implementación es más rápida. Poner en marcha un sistema interoperable con FHIR es más rápido comparado con otros estándares como HL7 v2.
Healthcare: es un estándar hecho para salud. Puede ser usado para otras cosas pero no tiene mucho sentido hacerlo.
Interoperability: creado para intercambiar información entre 2 o más sistemas.
Resources: utiliza una arquitectura de alta conectividad de la WEB llamada “REST”, la cual se basa en “recursos”.

Aunque si le preguntas a uno de sus creadores, te responderá algo como:

“(FHIR) no es un estándar, es una comunidad que convive para facilitar el intercambio de datos en salud, usando tecnologías web”.

Esto de “comunidad” no se lo toman a la ligera. Hay muchos espacios digitales donde las personas pueden ser parte de FHIR, entre ellos: la documentación, chat, blogs y foro.

¿Por qué es importante FHIR?

FHIR es el “caballo de batalla” de HL7, lo que significa que hoy en día es el estándar por defecto a utilizar para proyectos de interoperabilidad en salud.

Hay algunas acciones de la organización HL7 que dan cuenta de esto:

El objetivo de FHIR es que sea un estándar de uso global.
Hay un “FHIR Accelerator” que te ayuda a implementar proyectos de interoperabilidad con FHIR asesorados por HL7 internacional.
El logo de HL7 cambió a uno muy parecido a FHIR 😉.

¿Cómo nace FHIR?

Hay estándares anteriores que son más usados en el mundo, como HL7 v2, pero la tecnología evolucionó más rápido que ellos. Nos movimos del mundo offline al mundo online, de desktop a mobile, de software a aplicaciones, de servidores al mundo cloud, de sistemas cerrados a APIs abiertas…

Mientras tanto, en el mundo de la tecnología nació REST, que es un patrón arquitectónico donde todo puede ser modelado como un recurso y donde todo puede hacerse en base a 4 simples operaciones: crear, leer, actualizar y destruir (operaciones CRUD).

Es así como REST marca los cimientos de FHIR (Fast Healthcare Interoperability Resources), permitiendo definir el mundo de la salud en recursos que puedan ser entendidos por clínicos y por informáticos.

¿Por qué FHIR y no otro estándar?

Hay varias razones por las cuales preferir FHIR por sobre sus predecesores. Algunas de ellas son:

FHIR fue hecho para implementadores.
Cuando haces desarrollos, la dificultad siempre existe. La pregunta es, ¿dónde movemos la dificultad?
Es fácil de implementar. En promedio, implementar otros estándares tomaba 1 año y medio, mientras que con FHIR son solo 6 meses.
Tiene posibilidad de “mapeo” a otros formatos. Es decir, es fácil transformar de FHIR a HL7V2 o CDA.
Mejor capacidad de comunicar información.
Costo de implementación bajos (500USD). Esto es considerando solo costo de diseño y costo del sistema base.

¿Dónde podemos encontrar ejemplos y proyectos que usan HL7 FHIR?

En la página simplifier podemos encontrar la documentación de proyectos a nivel global.

En Chile, algunas organizaciones que están usando FHIR: Araucanía sur, Iquique, El ministerio de salud, UC Christus, el metropolitano sur oriente y La clínica Alemana. Además, ya existe una Guía de implementación FHIR para Chile.

Recursos

Te dejo algunos recursos que te pueden ayudar a aprender o implementar FHIR:

Y si tienes alguna duda, puedes agendar una reunión con nosotros.

Cómo implementar un campo único en Firestore

Nicolás Gómez — Fri, 08 Jul 2022 14:00:00 GMT

Imagina que tienes que guardar un campo de RUT de pacientes en Firestore y que además tienes que preocuparte de no duplicarlos. ¿Cómo lo haces?

Firestore no tiene una forma nativa para guardar campos únicos, así que tenemos que usar técnicas para lograrlo.

En este post, veremos una técnica para guardar campos únicos, que podría ser usada para no duplicar registros en base al RUT.

Nota: El RUT es un número único implantado en Chile, que se usa como identificación tributaria. En registros clínicos, se suele usar para identificar al paciente de forma inequívoca.

¿Qué es un campo único?

Un campo único es un dato particular que debe ser único entre todos tus registros.

Estos van a depender de la aplicación que estés construyendo, pero algunos ejemplos que suelen ser únicos: identificadores, RUT de pacientes y correo electrónicos.

¿Por qué guardar un campo único en Firestore no es fácil?

Firestore no tiene la funcionalidad para guardar un campo único. No es como otros motores de base de datos donde puedes decir “mira, quiero que la propiedad rut sea única para todos estos registros”.

Para lograrlo, hay que usar distintas técnicas, y va a depender de tu caso particular.

¿Cómo podemos guardar un campo único?

En este artículo veremos dos formas, las cuales van a depender de tu situación particular.

La primera es la más sencilla: haz que el campo único sea el identificador de tu documento en Firestore. Te conviene esta solución cuando no puede existir un registro sin el dato.

La segunda es más complicada: crea una colección para tu campo único y controla la escritura mediante reglas de seguridad. Te conviene esta solución cuando no puedes usar la primera.

Alternativa #1: Haz que el campo único sea el identificador de tu documento en Firestore

Si tienes registros de pacientes y por requerimientos siempre existirán pacientes con RUT, puedes optar por esta alternativa.

Cuando crees pacientes, en vez de usar la función add():

firestore().collection('patients').add(patientData);

Tendrás que hacerlo con doc() y set():

firestore().collection('patients').doc(patientData.rut).set(patientData);

Luego te recomiendo agregar en Reglas de Seguridad que el ID del documento sea igual al RUT:

match /patients/{patientId} {
  allow create: if patientId == request.resource.data.rut;
}

Puedes validar también que patientId parezca un rut válido (mediante una expresión regular).

Nota: para validar el dígito verificador, tendrías que hacerlo en una Cloud Function, ya que en Firestore Security Rules no puedes usar loops (aunque quizás es posible hacerlo sin loops 🙃).

Alternativa #2: Crea una colección para tu campo único y controla la escritura mediante reglas de seguridad

Si no puedes optar por la solución anterior, tendrás que hacer algo más complicado.

La idea es tener una colección aparte, que sea como un mapa entre tu campo único y el ID del documento que lo tiene. Luego agregar validaciones mediante reglas de seguridad. A esta colección la llamaré identifiers.

El resultado final será que para cada registro de paciente, también existirá un registro en la colección de identificadores. Por ejemplo:

Paciente con ID = 5dedf…

Identificador con ID = 1111111-1, y patientId = 5dedf…

Para lograrlo, son dos pasos:

1) Agregar colección de identificadores

Al crear pacientes, ahora tenemos que también crear identificadores. Por ejemplo:

const patientRef = firestore().collection('patients').doc() // ID auto generado
const identifierRef = firestore().collection('identifiers').doc(patientData.rut) // ID de RUT

await identifierRef.set({ patientId: patientRef.id })
await patientRef.set(patientData)

Aquí estamos creando ambos documentos. El problema es que esta no es una operación atómica, es decir, si falla la creación de uno, el otro documento no se ve afectado.

Para solucionar este problema, tenemos que usar escrituras en lotes (Batch writes):

const batch = firestore().batch();
const patientRef = firestore().collection('patients').doc();
const identifierRef = firestore().collection('identifiers').doc(patientData.rut);

batch.set(patientRef, newPatient);
batch.set(identifierRef, { patientId: patientRef.id });

try {
  await batch.commit();
} catch {
  // Ocurrió un error. Quizás el RUT ya estaba en uso :)
}

Con esto tenemos listo la primera parte. Ahora debemos hacer que esta operación falle si el RUT está en uso.

2) Agregar reglas de seguridad para evitar duplicados

Si ya existe un paciente con el RUT, la creación de paciente debe fallar. Como estamos usando una transacción, basta con la siguiente regla de seguridad:

match /identifiers/{identifierId} {
  allow create: if 'patientId' in request.resource.data;
}

Encapsulando la lógica anterior en una función llamada createPatient:

async function createPatient(patientData) {
	const batch = firestore().batch();
	const patientRef = firestore().collection('patients').doc();
	const identifierRef = firestore().collection('identifiers').doc(patientData.rut);
	
	batch.set(patientRef, newPatient);
	batch.set(identifierRef, { patientId: patientRef.id });
	
	try {
	  await batch.commit();
	} catch {
	  // Ocurrió un error. Quizás el RUT ya estaba en uso :)
	}
}

Al intentar ejecutar el siguiente código, obtenemos el siguiente resultado:

await createPatient({ rut: '11111111-1', name: 'Chewy 1' })
// ^funciona, y crea al paciente y al identificador (id = 11111111-1)
await createPatient({ rut: '11111111-1', name: 'Chewy 2' })
// ^falla, identificador id = 11111111-1 ya existe, la operación se considera
// como un update, por lo tanto las reglas de seguridad la rechazan

Esto ocurre porque el segundo llamado está escribiendo sobre el identifier con ID igual a 11111111-1, como ya existe, estamos hablando de una operación update la cual no es permitida.

Pero la regla no evita que agreguemos los pacientes directamente:

// Las siguientes llamadas funcionan:
await firestore().collection('patients').add({ rut: '11111111-1', name: 'Chewy 1' });
await firestore().collection('patients').add({ rut: '11111111-1', name: 'Chewy 2' });

Ni tampoco evita que agreguemos identificadores cuando los pacientes no existen:

await firestore().collection('identifiers').doc('11111111-1').set({ patientId: 'no existe' })

Es por eso que necesitamos agregar las siguientes 2 reglas:

1) Cuando creo un identificador, verificar que el paciente existe:

function patientExists(identifierId) {
  let identifier = getAfter(/databases/$(database)/documents/identifiers/$(identifierId)).data;
  let patient = getAfter(/databases/$(database)/documents/patients/$(identifider.patientId)).data;
  return identifierId == patient.rut;
}

match /identifiers/{identifierId} {
  allow create: if patientExists(identifierId);
}

La función getAfter obtiene el documento asumiendo que la solicitud actual se realiza correctamente. Si el paciente no existe, la verificación fallará, ya que el getAfter del paciente fallaría.

2) Cuando creo un paciente, verificar que el identificador existe:

function identifierExists(patientId) {
  let patient = getAfter(/databases/$(database)/documents/patients/$(patientId)).data;
  let identifier = getAfter(/databases/$(database)/documents/identifiers/$(patient.rut)).data;
  return identifier.patientId == patientId;
}

match /patients/{patientId} {
  allow create: if identifierExists(patientId);
}

Esto es lo mismo que la regla anterior, pero desde el punto de vista del paciente.

Gracias a estas dos reglas, los casos anteriores funcionan como deberían:

// Prueba 1: ambas llamadas fallan porque no existe identifier
await firestore().collection('patients').add({ rut: '11111111-1', name: 'Chewy 1' });
await firestore().collection('patients').add({ rut: '11111111-1', name: 'Chewy 2' });

// Prueba 2: falla porque no existe paciente
await firestore().collection('identifiers').doc('11111111-1').set({ patientId: 'no existe' })

La única forma de crear pacientes ahora es con una operación atómica, como la que tenemos en la función createPatient.

Conclusión

En este artículo vimos como implementar la funcionalidad de “campo único” en Firestore.

Como ejemplo, nos pusimos en la situación donde queremos guardar pacientes con un campo único “RUT”, que es un identificador único que tienen los ciudadanos en Chile 🇨🇱. De todos modos, puedes usar las mismas técnicas para otros tipos de identificadores, tales como pasaporte, nombres de usuario o incluso correos.

Las técnicas que vimos son 2:

La fácil, que es utilizando tu campo único como ID del documento.
La difícil, que es utilizando una colección auxiliar que funciona como un registro que guarda los valores únicos.

Me gustaría destacar que las técnicas mostradas le falta una capa adicional de privacidad, ya que el RUT estaría visible en el administrador:

Además, ¿qué pasa si el campo único tiene caracteres que a Firebase no le gusta en sus IDs?

Y solo vimos un único identificador, ¿cómo podemos hacer que existan otros tipos de identificadores? Por ejemplo, permitir que pacientes tengan RUT o Pasaporte.

A continuación te dejo contenido extra de cómo abordar estos requerimientos.

Extra: Cómo esconder el identificador

Si no quieres que tu campo único esté visible desde Firebase:

Puedes “ofuscar” el identificador, de manera que en vez de guardar el RUT, guardes su valor encriptado.

Para esto, tienes que usar alguna función que esté disponible en Cloud Firestore Rules, por ejemplo, md5 o sha256.

Usando sha256, el ID del documento ahora será el RUT encriptado:

const patientId = sha256(patientData.rut)
firestore().collection('patients').doc(patientId).set(patientData)

Y tendrías que actualizar las reglas de seguridad para verificar que el RUT del paciente sea igual al RUT encriptado:

function verifyPatientId(patientId, patientData) {
  return patientId == hashing.sha256(patientData.rut).toHexString().lower();
}

match /patients/{patientId} {
  allow create: if verifyPatientId(patientId, request.resource.data);
  allow update: if verifyPatientId(patientId, request.resource.data);
}

Así, el ID en vez de ser 11111111-1, queda en 5dedf71e6903bbb3c0b08ab5d94db62a4a5dea268bf2ef8d591089345989f82f

El código de la segunda técnica bajo ofuscación te lo dejo como ejercicio 😆

Sobre nosotros

Nicolás Gómez — Tue, 28 Jun 2022 18:00:00 GMT

El blog de Nessy es un blog sobre tecnología en salud, escrito y mantenido por Eliana Quijada y Nicolás Gómez.

Nace el 2020 como una forma de documentar y compartir nuestros aprendizajes sobre el mundo de tecnología en salud, con el objetivo de crear puentes entre ambos mundos.

¿Por qué “Nessy”?

Cuando fuimos a Escocia en 2017, nos dimos cuenta que en las tierras altas hay muchos lugares icónicos con sufijo Ness (Loch Ness, Inverness, etc).

Amamos Escocia y también amamos programar. Así que cuando creamos nuestra empresa, se nos ocurrió unir ambos conceptos en una palabra: Codeness, que vendría a ser algo como “zona de código”.

Luego fue natural usar a “Nessy” (el monstruo del Lago Ness) como nuestra mascota, y cuando armamos el Blog, decidimos que “El Blog de Nessy” venía muy bien.

Autores

Eliana Quijada

Eliana es de profesión Enfermera (de la Universidad de Chile) y además es Programadora. Tiene más de dos años de experiencia creando software en el ámbito de la salud, y es Diplomada en en Emprendimiento e Innovación en Salud Digital.

Una duda recurrente es cómo una enfermera ahora se dedica a la programación. Eliana habló sobre esto, puedes verlo en el video “De Enfermera a Desarrolladora” en YouTube. También escribió un artículo llamado “Iniciando una carrera Tech desde Enfermería”.

Puedes contactarla a través de su LinkedIn.

Nicolás Gómez

Nicolás es de profesión Ingeniero Civil en Computación (de la P. Católica de Chile). Tiene más de 9 años creando sistemas informáticos, y además es Diplomado en Emprendimiento e Innovación en Salud Digital.

Si bien no tiene experiencia clínica, ha trabajado creando aplicaciones en el ámbito de la salud desde el 2017. Primero trabajó para una start-up (nacida en Silicon Valley) que se dedicaba a crear productos para mejorar hábitos alimenticios. Luego, junto a Eliana el año 2021, crearon “Apposito”, una aplicación para documentar heridas de pacientes.

Puedes contactarlo a través de su LinkedIn.

Cómo fue trabajar 2 semanas desde Reino Unido

Nicolás Gómez — Wed, 01 Jun 2022 22:00:00 GMT

Con Eliana viajamos a Reino Unido durante 5 semanas, las primeras dos fue de trabajo remoto y las últimas 3 vacaciones.

Las semanas que estuvimos trabajando fue para hacer un mini experimento de “nómadas digitales”. A ambos nos gustaría estar un tiempo en esto, y qué mejor que aprovechar un viaje que ya teníamos programado para hacer una prueba inicial.

La primera semana la hicimos en Londres hospedados en el departamento de un amigo. Así que ahí teníamos todas las comodidades, como lavadora, escritorio, cocina y refrigerador. La segunda semana fue en Edimburgo, nos quedamos en un hotel cerca del centro de la ciudad.

De este breve experimento, me gustaría compartirte 7 observaciones y aprendizajes que tuvimos.

1) Es posible conocer nuevos lugares y trabajar… pero no es “gratis”

Eli trabaja full-time, con horario de 9:00 a 18:00 en horario de Chile. Ese horario traducido a Reino Unido es de 14:00 a 23:00.

Suena perfecto para poder salir a recorrer en las mañanas, almorzar y luego trabajar hasta tarde.

Hasta que lo haces y te das cuenta de que es bien cansador.

El horario en Chile tiene un descanso natural a la hora de almuerzo. Pero cuando estás viajando, prefieres hacer tu jornada de corrido de manera de terminar más temprano para tener la posibilidad de salir a conocer en la noche.

Los primeros días estás bien, pero luego de 1 semana se comienza a sentir el cansancio físico y mental que esta rutina conlleva. Y luego las mañanas ya no rinden tanto como al principio. De hecho, los últimos días nos despertábamos más tarde y la hora de buscar donde almorzar llegaba muy rápido.

Así que es posible viajar y conocer mientras estás trabajando, pero no es “gratis” desde el punto de vista del cansancio físico y mental.

2) Diferencia horaria con Chile está bien para trabajo asíncrono, no tanto si tienes que cumplir con el horario chileno

Como mencione antes, de 9:00 a 18:00 en Chile se traduce a 14:00 a 23:00 en Reino Unido.

Es perfecto para poder salir a conocer en las mañanas y trabajar en las tardes, pero hay algunos problemas cuando el horario es más estricto.

En nuestro caso, teníamos una reunión a las 14:00. Para poder estar online a esa hora, significa que teníamos que encontrar un lugar para trabajar al menos a las 13:50, y uno para almorzar a las 12:50.

Esto pone ciertas restricciones a las actividades que haces en la mañana. Ya no es un “tengo hasta las 14:00”, es más bien un “tengo hasta las 12:00”. De cierta forma, se siente que estás trabajando desde que buscas un sitio para comer.

En un trabajo más asíncrono, donde las personas no tienen que estar conectadas en un horario particular, da más flexibilidad para viajar y conocer.

Al menos cada vez que nos movíamos teníamos una vista hermosa al Castillo de Edimburgo 😂:

3) A diferencia de Santiago, hay muchas atracciones, tiendas y lugares para comer que cierran temprano (17:00)

En Edimburgo, a pesar de ser capital de Escocia, muchas atracciones, tiendas y sitios para comer cierran temprano (17:00) en comparación con lo que se acostumbra en Santiago de Chile.

En un tour que hicimos después, nos dijeron que la sociedad allá valora el tiempo en familia, y por eso las jornadas laborales terminaban a una hora razonable de tal manera de priorizar el tiempo que pasas con tus seres queridos ❤️

Los Starbucks y otras cadenas similares donde tenías un lugar cómodo para trabajar cierran tipo 19:00. En nuestro caso, significaba que a las 18:45 teníamos que movernos al hotel, el cual no era muy cómodo para trabajar.

Si salías a comprar algo para comer después de las 19:00, lo más probable es que terminaras en el McDonald’s o algún otro punto de comida rápida, los cuales eran los únicos que estaban hasta más tarde. Incluso los bares comienzan a cerrar la cocina tipo 20:00.

La excusa es que era lo único abierto 🙄

Un aprendizaje aquí es que si necesitas trabajar hasta después de las 18:00, es mejor contar con un hospedaje que tenga disponible una mesa o escritorio cómodo para trabajar 😅

4) Muchas ubicaciones donde trabajar

Además de Starbucks, hay otras cadenas muy parecidas donde puedes ir a trabajar. Algunas de ellas son Pret y Costa. Las instalaciones son muy buenas, el internet sin ningún problema para tener videollamadas. Por ejemplo, en este “Costa”, tienes una vista directa al castillo de Edimburgo:

En los parques abundan las sillas, así que es posible también trabajar con hermosas vistas.

5) Si vas a trabajar a un café, anda a verlo antes

Nos pasó una vez que necesitábamos estar a las 14:00 en un lugar con internet y cómodos.

Estábamos en Hyde Park (algo así como el “Central Park” de Londres), y vimos en el mapa que había muchos Starbucks cerca.

“Cómo no vamos a encontrar uno donde se pueda trabajar” — pensé.

Sin mentir, pasamos por 4 cafés antes de encontrar uno que sí tuviera un sitio habilitado para trabajar. Muchos locales eran pequeños, con pocos asientos y sin enchufes.

Terminamos en un Starbucks un poco apretado, pero fue suficiente:

Ahí aprendimos que si bien hay muchos cafés donde trabajar, es mejor siempre ir a darse una vuelta antes para ver que realmente se pueda.

6) Contratar internet móvil es una buena idea

Si bien no es difícil encontrar sitios con wifi público, es buena idea tener internet móvil de respaldo.

Imagina que tienes una reunión urgente y todavía no encuentras dónde sentarte a trabajar. Para esos momentos, es buena idea tener internet móvil.

Al menos en UK, nosotros contratamos un plan prepago de EE. El chip lo compramos en una tienda de abarrotes por 1 libra, y el plan lo contratamos por internet a 15 libras por un mes (5 GB de Internet).

7) La mejor parte son los fines de semana, ya que puedes aprovechar de conocer todo lo que no viste durante la semana

Lo mejor del tiempo que estuvimos trabajando fueron los fines de semana. Son básicamente dos días de mini vacaciones que puedes aprovechar para conocer a full. Aquí te olvidas del cansancio acumulado y te pones el sombrero de turista.

Nosotros fuimos a un Trekking a Box Hill (a unos 40 minutos de Londres) con nuestro amigo que nos hospedó y amigos de él. No sé como, pero caminamos unos 18 km 🤪

En Conclusión: lo volveríamos a hacer

La experiencia fue genial. Definitivamente, lo volveríamos a hacer 😊

Así que si te gusta viajar, conocer nuevos lugares y tu trabajo te lo permite, te lo recomiendo.

Recursos para aprender sobre HL7 FHIR

Nicolás Gómez — Thu, 30 Dec 2021 14:00:00 GMT

En este artículo encontrarás recursos para estudiar y comprender “HL7 FHIR”.

Introducción: ¿Qué es HL7 FHIR?

Antes de continuar: voy a responder esta pregunta desde un punto de vista no técnico y un poco más intuitivo. Espero que los expertos en “HL7 FHIR” no se ofendan 🙏

Es por eso que saber inglés es importante, ya que te abre puertas para poder comunicarte con el resto del mundo.

En sistemas informáticos pasa algo parecido… Distintos sistemas se pueden comunicar entre ellos, y para hacerlo, se ponen de acuerdo en el “lenguaje” en el cuál van a intercambiar información.

En el ámbito de salud, es muy importante que apuntemos como sociedad a que todos los sistemas de salud hablen entre ellos. Y para eso, es necesario que se haga en un lenguaje “común”, algo así como sería el Inglés.

Finalmente, cuando dos sistemas informáticos son capaces de intercambiar información entre ellos, decimos que “interoperan” o que son “interoperables”.

Qué cosas hay que saber previamente para aprender FHIR

En la introducción mencioné que FHIR es como el “Inglés” pero para sistemas informáticos. Es por eso que cuando haces un curso de FHIR, te bombardean de términos informáticos como “APIs” y “RESTFul”, muchas veces muy abstractos de entender para alguien clínico que está lejos de ese ámbito más computín. Además, en los cursos que he hecho yo (del CENS), no hay una “nivelación” ni nada por el estilo.

¿Qué cosas son necesarias saber para no perderse tanto?

Lo primero, hay dos cosas que veo relevantes:

¿Cómo funciona Internet?: Puedes ver este video explicativo en español https://www.youtube.com/watch?v=rw41W8crZ_Y (10 minutos).
¿Qué es una API?: para que dos sistemas hablen entre sí, tienen que hacerlo mediante algo que se llama “API”. ¿Qué rayos es eso? Bueno, aquí hay dos posts en español que buscan explicarlo:
- https://plata.news/blog/que-es-una-api/
- https://blog.fintoc.com/que-son-las-famosas-apis/

Saber más o menos como funciona internet te hará aterrizar ideas sobre cómo los sistemas se comunican. El concepto de “API” es muy utilizado por informáticos y en FHIR, así que esas nociones te ayudarán a poder seguir el hilo en una conversación con un informático y a no perderte cuando lo nombren en el contexto de FHIR.

Lo segundo, la parte menos técnica de FHIR tiene que ver con un concepto llamado “Interoperabilidad”. Eliana, que es Enfermera y Desarrolladora, tiene una serie de artículos que habla sobre esto para el ámbito de la Salud, te recomiendo leerlos como introducción:

¿Qué es la interoperabilidad en salud? El primer post del blog se titula “Interoperabilidad en Salud”.
¿Qué son los estándares de interoperabilidad? Eliana continúa con la serie, esta vez hablando sobre “Estándares de Interoperabilidad”, concepto que verás si o sí en cursos de HL7 FHIR.
¿Cómo se aplica la interoperabilidad y los estándares en la vida real? Eliana da un ejemplo de interoparabilidad en salud, para así bajar los conceptos a un caso clínico.

Nota: no es necesario entender al revés y al derecho estos conceptos ni menos ser un experto. Pero sí es muy útil tener una noción de las cosas para no perderse tanto mientras estudias sobre FHIR.

Aprendiendo sobre FHIR

Documentación oficial

La página oficial del estándar es https://www.hl7.org/fhir/, donde puedes encontrar toda la información en inglés.

El 15 de octubre del 2021 fue el lanzamiento oficial de la guía CORE de HL7 Chile, la cual puedes ver aquí. La gracia de la guía es que está pensada para el contexto de Chile, de manera de que los que quieran implementar el estándar tengan una base sólida para partir.

Cursos y Capacitaciones

Creo que una de las formas más efectivas de aprender sobre estos temas es gracias a cursos y capacitaciones. Lamentablemente la mayoría de estos son síncronos, es decir, hay que esperar a que la institución que los imparte haga una nueva versión de los cursos.

En Chile, el CENS ha hecho varios cursos y capacitaciones, las cuales puedes ver en https://cens.cl/soluciones/capacitaciones/

Nota: Publiqué mis apuntes del curso “HL7 FHIR: Principios y Fundamentos” en https://blog.codeness.io/hl7-principios-y-fundamentos/

Contenido existente en español

En YouTube hay algunas clases y eventos en Español. Te recomiendo estas porque las vi y encontré muy buenas:

“Interoperabilidad en Sistemas de Información en Salud”: https://www.youtube.com/watch?v=twl2Y9hlsuM
“Startups on FHIR”: https://www.youtube.com/watch?v=Oey55UrRDYA
“Tech Connect 2020”: https://youtu.be/B8S5prbmHIQ

Libros

Parte de la bibliografía de los cursos que da el CENS:

El libro blanco de Interoperabilidad en Salud (link)
Revisión de estándares de interoperabilidad para la eSalud en Latinoamerica y el Caribe (link)
Principles of Health Interoperability: SNOMED CT, HL7 and FHIR (link)

Firebase en Salud 🔥

Nicolás Gómez — Mon, 13 Dec 2021 14:00:00 GMT

Imagina que se te ocurre crear un producto para el área de salud. Que gastas horas y horas y luego te das cuenta que la tecnología con la que construiste el producto no cumple con leyes o regulación…

Por qué salud es distinto a otras industrias

A veces fantaseo con crear es un software parecido a Mailchimp (email Marketing), pero centrado en la privacidad de los suscriptores. Si quisiera hacerlo, desde el punto de vista tecnológico, podría comenzar a programar un Producto Mínimo Viable (MVP) solo pensando en lo que quiero construir.

Pero para productos en salud, es otro el cuento. Cuando creas software en salud, la dignidad humana va primero (qué mal tener que ser explícito en esto…), y esto te hará cuestionar muchas cosas a la hora de construirlo. Sí, lo siento, aquí no tiene entrada el “move fast and break things” clásico del mundo start-up 🤭

En consecuencia, en esta área hay muchas aristas de las que hay que preocuparse y tenemos que ser muy conscientes del stack tecnológico que elegimos. O al menos más si lo comparamos con otros rubros como educación, empleabilidad o productividad (lo digo porque tengo experiencia en ellos).

Dicho esto, ¿cómo saber si mi elección de tecnología está bien para salud? Y en particular, ¿Es razonable usar Firebase para crear este tipo de productos?

A modo resumen: Firebase es una muy buena opción, pero hay que tener ojo 👀 por eso partiré con un breve resumen el Marco regulatorio en que nos movemos, y luego hablaré sobre Firebase en sí.

Nota: Firebase es un conjunto de herramientas que te simplifica la creación de aplicaciones web o móviles. Está destinada a programadores que quieren iterar sus productos más rápido.

El marco regulatorio ⚖️

Aviso: No soy experto en temas regulatorios. De profesión soy Ingeniero Civil en Computación y algo manejo por formación (Diplomado de Emprendimiento e Innovación en Salud Digital) y por investigación propia. Así que puede ser que lo que te diga aquí no sea 100% preciso, y ante dudas es mejor consultar con una abogada.

Las leyes más bakanes que buscan proteger a los usuarios o pacientes y su información son el GDPR (Europa) e HIPAA (Estados Unidos):

GDPR es una regulación de la UE implementada para proteger la información de identificación personal (PII) del usuario y hacer que las empresas cumplan con un estándar más alto en lo que respecta a cómo recopilan, almacenan y usan estos datos.
HIPAA es una ley creada para proteger la información confidencial de la salud del paciente (PHI) para que no se divulgue sin el consentimiento o conocimiento del paciente.

Lamentablemente en Chile no llegamos a esos niveles. Sin embargo, sí hay una regulación que cumplir:

Ley de protección a la vida privada (19.628)
Ley de derechos y deberes del paciente (20.584)

¿Cuándo hay que cumplir con GDPR o HIPAA?

Tengo entendido que si tu software va a funcionar para pacientes de USA (ejemplo, colocas que tu APP esté disponible para descarga en ese país), entonces tienes que cumplir HIPAA. Mientras que si tu software tiene usuarios residentes en Europa, tendrás que cumplir con GDPR.

Así que una regla general es que tienes que preocuparte de la regulación del país donde quieres implementar tu solución. Por ejemplo, si es solo en Chile 🇨🇱, no tienes que cumplir GDPR ni HIPAA. Solo estás obligado a cumplir con la regulación local, donde está la ley 19.628 y la 20.584

Sin embargo, es una buena práctica crear software pensando en cumplir regulaciones más estrictas, ya que estas fueron creadas para proteger a los pacientes (HIPAA) y es una forma de ser proactivo, sobre todo cuando nuestra regulación no lo hace.

Algunos aspectos importantes de la regulación Chilena 🇨🇱

En mi emprendimiento previo, “TeeshMe”, un estudiante podía subir una foto de un ejercicio de logaritmos y un profesor le iba a decir paso a paso cómo resolverlo. Con el tiempo, podríamos haber creado algoritmos (con inteligencia artificial) que entregaran la solución automáticamente.

Esto está perfectamente bien. Pero, ¿qué pasa si quiero automatizar el diagnóstico de cáncer uterino con un algoritmo?

Antes de darte la respuesta, algunos datos que son de vital interés al momento de crear software en salud en Chile:

Ficha clínica: es un documento donde se registran antecedentes relacionados con la salud de las personas (sí, puede ser digital).
Tratamiento de datos: básicamente cualquier operación (automatizada o no) sobre datos.

Sobre la ficha clínica:

Toda información que surja de la Ficha clínica se considera como información sensible.
Los únicos que tienen acceso a la ficha clínica son prestadores relacionados directamente con la atención (además del titular o su representante legal). Es decir, un administrador de sistema o un programador no debería poder acceder a dicha información.

Sobre tratamiento de datos:

Solo puedes hacer tratamiento de datos sensibles (ej.: Ficha clínica) cuando la ley lo autorice, exista consentimiento del titular o sean datos para determinar beneficios de salud a sus titulares.

En consecuencia:

¿Quieres utilizar datos para una investigación científica? I’m sorry, pero tienes que informar a las personas involucradas y estas tienen derecho a elegir su incorporación.
¿Quieres mostrar una imagen de una radiografía de un paciente en tu página web? Tienes que tener su autorización escrita.
¿Quieres crear un algoritmo predictivo en base la información de los pacientes en tu sistema? De seguro esa información es parte de la ficha clínica, por ende pasa a ser un dato sensible y en consecuencia estás haciendo “tratamiento de datos”, lo cual requiere que el titular lo consienta expresamente (da igual si lo tienes anónimo o no 😉).

Como puedes ver, automatizar la respuesta a una pregunta matemática (TeeshMe) es posible, ya que una imagen de ese estilo no es información sensible ni tampoco dato personal. Pero en el caso de automatizar un diagnóstico, este utiliza información sensible y personal, por tanto, es obligación contar con el consentimiento escrito del paciente.

Ahí radica la diferencia con otro tipo de aplicaciones. En salud, es muy fácil que información que recolectas sea considerado un dato sensible, y por ende, para hacer “tratamiento” (básicamente cualquier algoritmo que los use) necesitarás tener consentimiento escrito 😱

Sí, si puedes alojar la información en servidores extranjeros 🙊

Hay un mito persistente que dice que no puedes alojar información de pacientes en servidores externos. La verdad es que sí puedes, así que no hay problemas con que uses algún proveedor Cloud como Firebase, Heroku, AWS o Digital Ocean. Ale Mauro escribió sobre esto en ForoSaludDigital.

Puse una sección con esta información porque de verdad es un concepto erróneo que incluso informáticos que trabajan en salud lo han hecho perdurar (lo he escuchado en distintos cursos que he ido como estudiante).

Ahora sí… El caso de Firebase 🔥

Para crear Apposito, elegimos un stack tecnológico (conjunto de tecnologías) que se ajustara a mi experiencia y a la de Eliana. Esto nos llevó a elegir Firebase, ya que ambos teníamos conocimientos y experiencia en esta tecnología (en este post hay más información de la decisión).

Ya sabíamos las funcionalidades que íbamos a programar y que eran posible de implementar con Firebase. La pregunta que quedaba era: ¿es razonable usar esta tecnología en salud? ¿Existe alguna razón para no usarla?

Firebase y regulación ⚖️

La respuesta corta es: la mayoría de servicios de Firebase cumplen con HIPAA (puedes ver el listado completo aquí). Y al cumplir con HIPAA, creo ya cumples con todo lo que te exige la ley en Chile 🎉 y a la vez de GDPR (o al menos, gran parte).

En nuestro caso, usamos Firestore (base de datos), Firebase Cloud Functions (operaciones en la nube), Cloud Storage (para guardar imágenes) y Cloud Identity (para inicio de sesión), todos cubiertos por HIPAA.

Algunos servicios relevantes que no cumplen la regulación son Crashlytics (para reporte de errores en aplicaciones móviles) y Firebase Authentication (para manejar inicios de sesión). Ambos pueden ser muy importantes a la hora de crear APPs en salud, ¿qué hacer entonces?

En el caso de Crashlytics, puedes usar una alternativa que cumpla HIPAA, aunque la mayoría son de pago. O simplementar utilizar el diagnóstico por defecto de Android e iPhone. Quizás hay información extra que no tendrás, pero al menos no estarás ciego.
En el caso de Firebase Authentication, puedes usar Cloud Identity (que fue lo que usamos nosotros).

Nota importante: si haces aplicaciones para profesionales de salud (ejemplo, para enfermeras), quizás no es tan importante con que todo lo que uses cumpla HIPAA. Mi razonamiento es que la información de la persona que usará la APP no es PHI (información protegida de salud). Sin embargo, la información que ingresen de terceros si es PHI, y es ahí donde hay que tener cuidado.

Firebase y casos de uso que querrías implementar en salud 💉

A grandes rasgos, hay muchos casos de uso que son posibles de realizar con Firebase. A continuación van 4 ejemplos de casos de uso y qué tecnología de Firebase usar para implementarlo (será un poco más técnica esta parte 👨‍💻👩‍💻)

Ficha clínica, Información de pacientes, Información de profesionales, etc.

Puedes utilizar Firestore, ya que es una base de datos.

Para cumplir con regulación (por ejemplo, hacer que una enfermera pueda ver información solo de sus pacientes), tendrás que implementar cierto manejo de permisos, para lo cual tienes que usar Firestore Security Rules.

Imágenes de pacientes (lunares, heridas, etc.), archivos con información de exámenes, etc.

Puedes usar Cloud Storage, ya que te permite almacenar distintos tipos de archivos (PDF, imágenes, etc.).

Si quieres manejar permisos de lectura sobre estos archivos, tendrás que utilizar Cloud Storage Security Rules.

Sin embargo, para permisos más elaborados, tendrás que dejar todos los archivos privados y permitir que usuarios accedan a ellos a través de Cloud Function (donde puedes manejar la lógica de acceso de forma muy personalizada).

Historial de cambios y de acceso

Es una muy buena práctica saber quién hizo qué respecto a la información de los pacientes, de manera de tener un historial de cambios.

Firestore tiene utilidades que te ayudan. Por ejemplo, con Cloud Firestore Triggers puedes crear fácilmente historiales de la ficha de un paciente. Sin embargo, la gran dificultad es que no puedes saber quién hizo los cambios, lo cual es muy relevante en salud.

Tampoco hay una manera fácil de saber qué usuario está leyendo cierta información (ej.: ¿quién leyó los datos personales de un paciente particular?).

Interoperabilidad

Puedes hacer que tu solución sea interoperable (que se pueda comunicar con otros sistemas) implementando una capa de HL7 FHIR con Cloud Functions. No es una tarea fácil, pero es posible.

⚠️ No por usar un servicio que cumple con la regulación estás cumpliendo con la regulación

Para construir una aplicación, de seguro que vas a usar servicios en la nube o código de terceros.

Podríamos decir que todos estos servicios externos que uso son legos con los cuales construyo mi aplicación.

Si mis piezas cumplen con cierto estándar, al armar mi figurita también tengo que preocuparme de seguir cumpliendo el estándar. Así que no es suficiente con que las partes pequeñas cumplan, la figura final también debe hacerlo.

Ejemplo un poco más técnico: usar Firestore para guardar datos de ficha clínica donde toda la información está pública. Firestore cumple HIPAA, pero como no me preocupé de dejar la información privada, cualquier persona puede ver la información y por tanto, rompo HIPAA.

Conclusión

Cuando creamos software en salud, debemos ser muy cuidadosos con los servicios que usamos y con las librerías que instalamos. Por un lado está la parte regulatoria, y por otro el aspecto ético: tenemos la obligación ética de crear aplicaciones que respeten la dignidad humana.

En este sentido, Firebase es una excelente herramienta que te permite prototipar rápido y cumple con regulaciones como HIPAA y GDPR ❤️ además tiene distintas funcionalidades que te permitirán lograr que la aplicación que crees también cumpla con la ley.

Sin embargo, mientras desarrollábamos Apposito, nos encontramos con que algunos casos de uso como historial de cambios o historial de acceso no son tan fáciles de implementar debido a limitaciones en Firestore.

3 aspectos relevantes en salud digital

Nicolás Gómez — Mon, 12 Jul 2021 16:00:00 GMT

La pandemia nos hizo darnos cuenta de muchas falencias digitales en Chile. Si bien contamos con una de las conectividades más alta de la región (fuente), es pan de día a día ver como los bancos, AFP, isapres y otras instituciones se llenan con personas haciendo trámites que podrían hacer sin contacto (en línea), pero no lo hacen por carecer de conocimientos.

Esto no es extraño, ya que el 42% de los Chilenos carecen de las herramientas básicas para la economía digital (fuente). Muy probablemente nos encontramos como sociedad en el nivel 1 de alfabetización digital (Lankshear, C., & Knobel, M.), muy lejos del tercer y último nivel que habilita la transformación digital. Si bien estos niveles no plantean un proceso lineal, debemos tener competencias básicas para habilitar usos digitales que permitan nuevos tipos de innovación y creatividad.

Debido a este contexto, no es raro ver fracasar planes de transformación digital e innovación en Salud Digital en Chile. A continuación me gustaría centrarme en 3 aspectos que considero relevantes al hablar de Transformación Digital e innovación en el ámbito de salud, y por qué debemos trabajarlos para poder mejorar la salud de las personas.

El primero es no olvidar que los individuos y las interacciones van sobre los procesos y las herramientas. Este es un principio fundamental de las metodologías ágiles, un potenciador de la transformación digital de muchas compañías en el mundo. Debe existir una inversión en las personas si queremos que un plan de digitalización funcione, sobre todo considerando que el nivel de alfabetización que tenemos en Chile es bajo.

El segundo aspecto es tener especialmente cuidado en los casos de éxito y filosofía que utilizamos en el ámbito de la salud. Sé que es impactante ver como empresas de la nada se convirtieron en imperios digitales. Facebook, Amazon, Apple, Netflix y Google, las famosas “FAANG”, fuentes de inspiración, creadoras de innovación, facilitadoras de la transformación digital y cometedoras de acciones poco éticas. Estas empresas con crecimiento exponencial tienen la filosofía de “crecer a todo costo”, mientras más extractivos, más adictivos y más virales mejor. La dignidad humana debe estar al centro de la salud digital, es por eso que debemos elegir con cuidado nuestras fuentes de inspiración y mentores.

Esto me lleva al tercer y último aspecto: los incentivos. La digitalización nos permite medir cosas que antes no. Podemos ver que tan eficiente somos y podemos optimizar OKR (Objectives and Key Results) de negocio que nos importan. Pero, ¿cuáles son esos objetivos? ¿Cuáles son esas métricas? El fin último será función de los ingresos que una institución tenga, pero los incentivos económicos no están alineados con la salud de las personas. El sistema está hecho para enriquecerse de las personas enfermas. No le interesa tener y mantener personas sanas. Es más caro mantener una persona diabética que prevenir con actividad física. Bajo este contexto, optimizar esta máquina siempre irá en contra de lo que realmente importa, mantener a las personas sanas.

Sé que la salud pública es un sistema dinámico y complejo, que tiene muchas más aristas de las que planteadas en este ensayo. Sin embargo, estoy convencido de que mejorando los puntos aquí expuestos (las personas primero, dignidad humana al centro e incentivos en favor de la salud) nos permitirá colocar a la tecnología a nuestro favor para mejorar la salud de todos los Chilenos.

Referencias

Diario Concepción. (2019, 9 junio). Ocde: el 42% de los chilenos carece de herramientas básicas de digitalización. https://www.diarioconcepcion.cl/economia-y-negocios/2019/06/09/ocde-el-42-de-los-chilenos-carece-de-herramientas-basicas-de-digitalizacion.html
ECLAC. (2017). State of broadband inLatin America and the Caribbean. https://repositorio.cepal.org/bitstream/handle/11362/43670/1/S1800532_en.pdf
Lankshear, C., & Knobel, M. (2008). Digital Literacies; Concepts, Policies and Practices: 30 (2nd ed.). Peter Lang Us.
Manifiesto por el Desarrollo Ágil de Software. (2001). Agile Manifesto. https://agilemanifesto.org/iso/es/manifesto.html
Heinemeier, D. (2017, 27 febrero). Exponential growth devours and corrupts. Signal v. Noise. https://m.signalvnoise.com/exponential-growth-devours-and-corrupts/
El Desconcierto, Freixas, M., & Hullin, C. (2021, 18 marzo). Carol Hullin, de La Legua al Banco Mundial: «Cuando se hace negocio con la pobreza, no quieres que ese negocio termine». El Desconcierto - Prensa digital libre. https://www.eldesconcierto.cl/reportajes/2021/03/16/carol-hullin-de-la-legua-al-banco-mundial-cuando-se-hace-negocio-con-la-pobreza-no-quieres-que-ese-negocio-termine.html

Un enfoque práctico con HL7® FHIR®

Nicolás Gómez — Mon, 14 Jun 2021 16:00:00 GMT

Clase 1: Modelado

En esta clase nos enseñaron a modelar una solución utilizando HL7® FHIR®.

Para esto, hay que considerar los “puntos de interoperabilidad”:

Identificar punto de intercambio de información: Usando el Diagrama BPMN establecer los puntos en los cuales se requiere intercambiar información.
Identificar los grupos de información: Establecer los conjuntos de información que tendrán relación en cada punto de intercambio.
Identificar la información por grupo: Para cada grupo de información, se debe establecer y detallar cada dato, realizando una correcta definición para evitar cualquier tipo de ambigüedad.
Establecer mecanismos de intercambio de datos: Definir estándar, seguridad y otras características no funcionales, requeridas por el proceso.

En otras palabras, hay que “modelar” el intercambio de información y definir qué es lo importante, qué datos son los que estamos intercambiando y cuándo se genera el dato.

Conjunto mínimo de datos (CMD)

El conjunto mínimo de datos (CMD) nos permite:

Satisfacer todas las operaciones e intercambios de datos en un determinado proceso.
Establecer datos, propiedades, tipos de datos y descripciones de cada dato.
Permite tener un mirada global de la información durante un proceso.

Por ejemplo:

Modelado

El proceso de modelación es cuando ya tenemos claro los puntos de interoperabilidad y los CMD, y se trata de definir la solución al problema utilizando los estándares de interoperabilidad.

Con HL7 FHIR, esto significa pensar, analizar e investigar para saber qué recursos tenemos que usar, y qué atributos son los importantes para nuestro CMD.

La recomendación aquí es:

Utilizar la documentación oficial.
Identificar los Recursos utilizando “Scope and Usage”.
Identificar Recursos en base al CMD y sus Grupos de Datos.
Identificar las estructuras de los recursos HL7 FHIR para asociar el CMD.
Identificar elementos especiales:
- Conjuntos de valores asociados a un elemento o campo.
- Datos que no hacen match con el recurso HL7 FHIR seleccionado.
- Elementos o campos que serán requeridos para búsquedas.

Es posible hacer una modelación visual de los recursos involucrados utilizando una herramienta gratuita llamada “ClinFHIR” (link):

Clase 2: Metodología

Esta clase me gustó mucho, ya que te arma el rompecabeza (utilizando las piezas de las clases anteriores) para enseñarte una metodología para aplicar todo lo que aprendimos en el curso.

¿Qué es una metodología? Son pasos replicables para enfrentar un proyecto. El objetivo es ordenar (“paso a paso”) y que el método sea reproducible.

La metodología que nos presentaron tiene 2 niveles:

Diseño: ¿Cuál es el problema que queremos resolver? Hay que acotar el problema y el alcance.
Desarrollo de software: es construir el software, adaptable a cualquier metodología.

Fase 1: Conjunto mínimo de datos

Aquí hay que discutir con los stakeholders y llegar al consenso sobre qué datos son importantes.

El resultado es el conjunto mínimo de datos (CMD). Hay casos en los cuales puede que no tengamos un dato (por ejemplo, fecha de nacimiento).

Fase 2: Modelado

El CMD no es suficiente. Hay que conocer el modelo de negocio de los datos: ¿cómo se genera? ¿cómo se comparte?

En esta fase, modelamos la interoperabilidad entre los sistemas. Todo lo que es importante para el proceso de interoperabilidad. Es decir, no modelamos el negocio propiamente tal, sino que solo todo lo que tenga que ver con la interoperabilidad.

Fase 3: Estándares

Aquí hacemos match de lo que tenemos de las fases anteriores con un estándar (v2, FHIR, etc). Así que definimos el mapping, extensiones, perfiles, operaciones, coding, etc.

También modelamos la solución con clinFHIR.

Fase 4: Desarrollo de software

Creamos el prototipo (un software funcional). La metodología para crear el software es a libre elección, lo importante es que esté de acuerdo con el alcance del proyecto.

Hay que tener en cuenta tanto requisitos funcionales (las cosas que debe hacer) como los no funcionales (los aspectos que harán que el software sea útil).

Fase 5: QA

Una vez ya tenemos el prototipo, tenemos que comenzar a probarlo para asegurarnos que funcione bien (sin errores, que se entienda, etc).

Fase 6: Despliegue

A esta altura ya tenemos un prototipo que funciona. Lo siguiente es ponerlo en marcha para que los usuarios puedan comenzar a utilizarlo.

En esta fase dejamos nuestra implementación en simplifier (si corresponde) y también hacemos tests de carga para ver si nuestro sistema funciona sin problemas en un escenario realista.

Operaciones con HL7® FHIR®

Nicolás Gómez — Wed, 12 May 2021 16:00:00 GMT

Clase 1: Arquitectura FHIR y REST

Esta clase fue dictada por Alejandro Medina donde vimos:

Arquitectura FHIR
Fundamentos REST
Operaciones básicas REST
Demo

Arquitectura FHIR

Principios arquitectónicos

Antes de continuar con los apuntes, me gustaría hacer un paréntesis sobre “arquitectura”. En software, cuando hablamos de arquitectura, nos referimos a los “planos” de un sistema informático. Es parecido a los planos de las casas o edificios, pero aquí los planos me indican cómo se organiza un software.

El profesor nos comentó sobre los “principios arquitectónicos”, es decir, la mentalidad con la cual se pensó la arquitectura de FHIR, que son:

Reutilización y composición: Los Recursos FHIR® están diseñados para coincidir con los requisitos comunes de muchos casos. Los perfiles o extensiones nos permiten adaptar para nuestros casos particulares. Por ejemplo, en Chile, podemos usar extensiones para agregar campos de Nombre y apellido, previsión y dirección.
Escalabilidad: (cuando hablamos de escalabilidad, nos referimos a que el sistema va a soportar muchas peticiones o conexiones de usuarios). En FHIR se logra gracias a que las transacciones (las operaciones sobre recursos) no tengan estado (cada operación funciona de manera independiente), lo cual facilita que dentro de un grupo de servidores se puedan distribuir las transacciones (se puede paralelizar carga para evitar cuellos de botella).
Rendimiento: los recursos FHIR® son livianos y adecuados para el intercambio (para un computador es fácil y rápido generar o leer un recurso XML o JSON).
Usabilidad: los recursos FHIR® pueden ser entendidos por perfiles técnicos y no técnicos, incluso en el caso de no conocer la sintaxis de JSON o XML es posible leer e interpretar la información de un recurso.
Fidelidad de datos: mecanismos incorporados para la asociación y validación de terminología clínica (es decir, un programa puede validar que los datos respeten las reglas y normas definidas).

Descomposición FHIR

FHIR puede “descomponerse” (documentación) en los siguientes módulos:

Modelo de información (Information Model): los componentes de FHIR relacionados con la creación de recursos.
Modelo de conformidad (Constraints): los componentes de FHIR que abordan las limitaciones y la validez.
Terminología (Terminology): los componentes de FHIR relacionados con terminologías clínicas y ontologías
Uso (Usage): el componente de FHIR que aborda el uso de FHIR para su uso en tiempo de ejecución (es decir, la API REST de FHIR).

Imagen extraida de documentación oficial FHIR

Implementación de servidores FHIR

Un servidor REST FHIR es cualquier software que implementa las API FHIR y utiliza recursos FHIR para intercambiar datos. El diagrama siguiente describe las definiciones de la interfaz FHIR. Los métodos se clasifican en:

iServeInstance: métodos que realizan operaciones Get, Put o Delete en un recurso
iServeType: métodos que obtienen información de tipo o metadatos sobre recursos
iServeSystem: métodos que exponen o habilitan comportamientos del sistema.

Imagen extraida de documentación oficial FHIR

Nota: esto fue traducido de la documentación.

Introducción a REST

En la clase no explicaron mucho sobre qué es REST, así que aquí va un resumen.

REST se refiere a un conjunto de principios de arquitectura que es muy adoptado por las aplicaciones web. Cuando hablamos de principios de arquitectura, nos referimos a ideas y reglas que se deben cumplir.

REST nos va a decir que la aplicación web debe hacer “esto” y “esto otro” (lo veremos más adelante). Cuando una aplicación web cumpla con todo lo que dice REST, diremos que es una “aplicación web RESTFul”.

Ok, entonces REST nos “obliga” a hacer las cosas de cierta manera. ¿Y qué nos pide hacer?

REST nos pide que nuestra aplicación web organice su información en recursos. Por eso FHIR está organizado en recursos y puedes ver que hay un recurso para Paciente, otro para Observación, entre otros.

Las siglas REST se refieren a REpresentational State Transfer. Esto quiere decir que cuando solicitamos información a una aplicación web RESTFul (que cumple con REST), esta nos transferirá una representación del estado del recurso solicitado.

Por ejemplo, cuando solicitamos la información de un Paciente particular, una API FHIR nos entregará el estado de ese paciente, incluyendo información como el nombre, dirección, entre otras cosas. El recurso estará representado comúnmente en formato JSON o XML.

Fin del paréntesis.

REST

Los principios fundamentales de REST son:

Cliente-Servidor: el cliente es un componente independiente del servidor (cuando hablamos de cliente, nos referimos a la persona o al software que utiliza una aplicación web).
Sin estado: Cada petición contiene toda la información para ejecutar una acción.
Cacheable: posibilidad de utilizar caché para peticiones recurrentes (es decir, la aplicación web recuerda que fue lo último que dijo y en vez de hacer todos los cálculos te da la respuesta anterior, permitiendo responder más rápido y utilizando menos recursos).
Interfaz Uniforme: simplifica y desacopla la arquitectura (interactuar con un recurso A lo mismo que interactuar con un recurso B).
Sistema de Capas: los componentes no pueden ver más allá de su capa (es decir, cuando hablo con una API REST no me interesa como guardan la información, solo me interesa que me la entregue).

Las aplicaciones web funcionan con el protocolo HTTP, que en resumen significa que habrá un “cliente” que le hará una solicitud a un “servidor” quien responderá con lo que le solicitaron. Por ejemplo, un cliente puede ser tu explorador Chrome, el servidor puede ser el servidor CENS, y la solicitud es ver el curso que estamos haciendo. El servidor CENS responderá con la información en formato HTML (página web) y Chrome nos mostrará de manera bonita y ordenada la información.

Request / Petición

Una solicitud se compone de:

Versión del protocolo: qué versión de HTTP se está usando.
Método: la acción que deseamos realizar, las cuales son:
- POST: para crear un recurso, los datos se especifican en el body (“Cuerpo del mensaje”)
- GET: para obtener uno o varios recursos
- PUT: para actualizar un recurso, lo cual significa reemplazar un elemento completo.
- DELETE: para eliminar un recurso (sin body).
URI identifica la entidad o recurso, permitiendo obtener un elemento en específico o todos. También puede incluir parámetros de búsqueda.
Cabeceras: características acerca de lo que se transmite. Aquí por ejemplo indicamos que queremos obtener la información en JSON o XML.
Cuerpo del mensaje: información del recurso (no todas las operaciones lo tienen). Aquí indicamos los datos del curso que queremos guardar (POST) o actualizar (PUT).

Responde / Respuesta

Una respuesta se compone de:

Versión del protocolo: qué versión de HTTP se está usando.
Código de estado: es un número que indica el estado de la respuesta.
- Respuestas informativas (100–199)
- Respuestas satisfactorias (200–299)
- Redirecciones (300–399)
- Errores de los clientes (400–499). Cuando entras a una página que no existe, aparece un 404 de “not found” (ejemplo).
- Errores de los servidores (500–599). Por ejemplo, WePlay se cayó porque mucha gente entró a comprar un PS5 a $499.990, si entrabas a la página aparecía un error “502”.
Cabeceras: características acerca de lo que se transmite. Por ejemplo, nos dirá que la información fue entregada en formato JSON.
Cuerpo del mensaje: aquí nos entrega la información que solicitamos.

Demo y Ejemplos

En la clase dieron un ejemplo de API REST de autos.

En una plataforma de venta de autos, nuestro recurso principal serán los autos. Por ejemplo, podemos tener un servidor web en autos.venta.cl que ofrece una URI autos para obtener los recursos de autos.

Como sabemos que la URI es autos, y que el servidor es REST, entonces sabemos que podemos crear, actualizar, leer y eliminar autos.

Leer (`GET`)

Obtener todos los autos (notar que el URI es /autos)

GET /autos HTTP/1.1
Host: autos.venta.cl
Accept: application/json

Obtener un auto que tenga id = 1 (notar que el URI es /autos/1)

GET /autos/1 HTTP/1.1
Host: autos.venta.cl
Accept: application/json

Obtener todos los autos de color azul (notar que el URI es /autos?color=azul). Aquí el color=azul es un parámetro de búsqueda

GET /autos?color=azul HTTP/1.1
Host: autos.venta.cl
Accept: application/json

En REST, si decimos que los recursos de auto están en el URI /autos, asumimos que un auto particular se encuentra en /autos/:id (con :id el identificador del auto)

Crear (`POST`)

Para crear un auto, tendremos que crear una solicitud POST a /autos:

POST /autos/ HTTP/1.1
Host: autos.venta.cl
Content-Type: application/json
Accept: application/json
{ "marca": "peugeot",  "color": "azul" }

Aquí podemos ver todos los elementos mencionados anteriormente:

Versión del protocolo: HTTP/1.1
Método: POST
URI /autos
Cabeceras: Las líneas que dice Content-Type y Accept
Cuerpo del mensaje: { "marca": "peugeot", "color": "azul" }

Actualizar (`PUT`)

Para actualizar el auto de id igual a 1, tenemos que hacer una solicitud PUT a /autos/1:

POST /autos/ HTTP/1.1
Host: autos.venta.cl
Content-Type: application/json
Accept: application/json
{ "marca": "toyota", "color": "rojo" }

En el body estamos actualizando la marca a toyota y la marca a rojo.

A diferencia de la operación para crear, aquí estamos editando un auto particular, por eso la URI es /autos/1.

Eliminar (`DELETE`)

Para eliminar el auto de id igual a 1:

DELETE /autos/1 HTTP/1.1
Host: autos.venta.cl
Accept: application/json

Preguntas en clases

¿Se pueden obtener todos los recursos sin paginar?

Sí, pero el servidor o el cliente pueden colapsar debido a la cantidad de información.

Nota: paginar es cuando obtienes la información de a poco, dividida en páginas en vez de toda la información.

¿Existe Graphql en FHIR?

Sí, hay discusiones e implementaciones pero no es normativo.

¿Las URI son RESTFul en FHIR?

Sí pero se ven un poco limitadas. Generalmente es /RECURSO y /RECURSO/:id (listado y uno en particular). Si queremos obtener asociaciones (por ejemplo, las observaciones de un paciente), se hace mediante búsqueda.

¿Podemos usar no-content en vez de 404?

No me acuerdo que dijo el profe 😂, pero si un recurso no existe, lo correcto es responder 404. “Lo correcto” es definido por estándar de HTTP. Si respondes no-content cuando debería ser 404, harás que los desarrolladores tengan que hacer chequeos adicionales en las aplicaciones, lo cual no es idóneo.

Nota: no content es una cabecera para indicar que mi respuesta no tiene contenido (sin body). Generalmente se usa cuando eliminamos un recurso.

Clase 2: Operaciones

Esta clase (por José María Andrade) fue sobre operaciones en FHIR. Parecido a los conceptos vistos sobre operaciones en REST, pero aplicadas en el estándar.

¿Qué es un Recurso?

Un Recurso es una entidad definida por el estándar con el propósito de facilitar el intercambio de datos de salud.

Se caracteriza por:

URL definida para acceder.
En su estructura se define el tipo de recurso
Posee un conjunto de elementos estructurados
Versionado

La mayoría derivan de DomainResource, heredando extensiones, texto, recursos contenidos, etc. Esto quiere decir que recursos distintos tendrán algunas propiedades en común provenientes de la definición de DomainResource (en programación esto se conoce como “herencia”).

Existe un recurso especial llamado Bundle el cual sirve para agrupar recursos. Un ejemplo del uso de Bundle es para resultados de búsqueda.

Operaciones básicas

GET [base]/Patient: obtiene listado de pacientes. Cuando aplicamos esta operación REST el servidor FHIR contesta con código de HTTP 200 (que significa ok, que todo salió bien) un JSON de tipo Bundle que contiene todos los recursos de ese tipo.
GET [base]/Patient/example: obtiene un paciente particular (el que tiene ID = example). Cuando aplicamos esta operación, el servidor FHIR contesta con un JSON (con código HTTP 200) que contiene el recurso solicitado.
POST [base]/Patient: crea un paciente nuevo. Cuando aplicamos esta operación junto a un body JSON que contiene la estructura de ese recurso, el servidor crea el recurso y responde con el recurso creado y un código HTTP 201 (que significa created, recurso creado exitosamente).
PUT [base]/Patient/example: actualiza un paciente particular (el que tiene ID = example). Cuando aplicamos esta operación junto a un body JSON que contiene la estructura de ese recurso, el servidor actualiza el recurso y responde con el recurso actualizado y un código 200,el history del recurso aumenta en 1.
DELETE [base]/Patient/example: elimina a un paciente particular (el que tiene ID = example). Cuando aplicamos esta operación rest el servidor FHIR contesta con un JSON (con código HTTP 204, no content, sin contenido) y elimina el recurso (más bien lo desactiva).

Como puedes ver, hay operaciones que tienen que ver con un recurso particular (todas las que tienen el ID en la URL) y otras que tienen que ver con el conjunto de pacientes (sin el ID).

La parte que dice [base] se refiere a la URL base donde se encuentra el servidor FHIR. Puede ser algo como https://www.example.org, y va a depender del servicio al cual nos queramos comunicar.

Además vimos dos operaciones más:

HISTORY: GET [base]/[resource]/[id]/_history/[x], donde [x] corresponde al número de la versión que queremos obtener. Nos sirve para obtener un recurso en una versión particular.
PATCH [base]/[resource]/[id], esta es una operación que nos permite actualizar un recurso (tal y como hace PUT) con la diferencia que aquí solo debemos indicar lo que queremos hacer. Cuando aplicamos esta operación junto a un body JSON que contiene la operación a ejecutar de ese recurso, el servidor actualiza el recurso y responde con el recurso actualizado y un código 200, el history del recurso aumenta en 1.

Los pasos para hacer un PATCH son:

Obtener el recurso que se va a modificar
Llevar el json/xml a un editor.
Agregar a los headers: “Content-type: application/json-patch+json”
Agregar el body relacionado a la operación: add, replace, remove. Ejemplo:
- Agregar: [{ "op": "add", "path": "/name/1", "value": {"given": "dos"} }]
- Actualizar: [{ "op": "replace", "path": "/name/1", "value": {"given": "uno"} }]
- Eliminar: [{ "op": "remove", "path": "/name/1" }]
Aplicar el PATCH sobre [base]/[resource]/[id]

Búsquedas en FHIR

Podemos realizar búsquedas de dos formas:

GET [base]/[recurso]/?[parametros]&_format=[mime-type]
GET [base]/[recurso]/_search?[parametros]&_format=[mime-type]

Donde:

base: Es la URL base del servidor FHIR.
recurso: Es el recurso con cual deseo interactuar, ej: Patient, Observation, etc.
parámetros: Son los parámetros de búsquedas que desea utilizar para obtener el resultado
_format: Es el formato en cual desea obtener el resultado de la búsqueda JSON o XML, una manera más elegante de realizar esta tarea es a través de HTTP headers.

Por ejemplo, para buscar a los pacientes que se llaman Nicolás: GET [base]/Patient?given=Nicolás

Clase 3: Perfiles y extensiones

¿Qué se puede hacer con un perfil?

Reglas de elementos que se usan y cuales no (podemos agregar restricciones).
Elementos nuevos que no están en la definición base (a través de extensiones, utilizar para requisitos específicos)
Reglas de terminología
Descripciones de elementos que permiten establecer un nexo con los requerimientos locales.

¿Para qué se usan?

Son parte de:

Guías de implementación, que a su vez son la formalización de los cambios realizados.
Paquetes o Releases.
- Esto es más o menos nuevo, crearon un repositorio de manera que los perfiles puedan ser descargables. Es decir, puedo instalar un perfil.
- Simplifier está incluido, así que podemos instalar cualquier perfil que esté en dicha página.
Capability Statement: qué se puede hacer y qué no.

¿Cuáles son los cambios aplicables?

Cardinalidad: 0..1, 0..n, 1..1, 1..n
Restringir valores por defecto.
Restringir datos mediante fhir path.
Restringir relaciones. Por ejemplo, una relación yo puedo decir que si o sí debe ser de cierto recurso.
Especificar cierta terminología.
Restringir relaciones a perfiles específicos.
Marcar atributos como is-modifier (cambia el contexto de lo que es), must support (son elementos con contexto nuevo que tiene que ser utilizado), maxLenght (máximo largo de texto), isSummary (para que sea parte del resumen).

¿Qué son las extensiones?

Son un tipo de dato especial.
Permiten extender un recurso base.
Permite extender elementos nuevos.
Se puede usar casi cualquier tipo de dato de los disponibles en la especificación.

Las extensiones se componente de una URL (generalmente ficticias, pero que le da sentido a la extensión) y de un valor.

El valor se guarda en una variable particular dependiendo del tipo de dato. Por ejemplo:

valueBoolean para valores de si y no
valueDateTime para hora y fecha
valueInteger para números
valueAddress para direcciones
valuePeriod para periodos de tiempo
valueString para textos

Como la extensión hereda de recurso base, podemos hacer una extensión de una extensión 🤯

Hay un registro general donde está el índice de madurez de las extensiones.

Finalmente, podemos buscar por extensiones, para lo cual debemos crear un SearchParameter.

¿Qué pasa si queremos extender con extensiones?

Lo primero que hay que hacer es ver si hay una que existe y que cubre nuestro caso de uso.

Preguntas

¿Qué pasa si tengo un sistema FHIR andando y luego lo perfilo? puedes listar pacientes de acuerdo a un perfil. Si quieres que todos lo cumplan, entonces tienes que actualizar tus datos.
¿Qué tan factible es tener aplicaciones SMART, si al final todos tienen que perfilar? Puedes hacer una APP de acuerdo a un perfil. Por eso son importantes las guías de implementación.

Introducción al Estándar HL7 FHIR

Nicolás Gómez — Sat, 01 May 2021 16:00:00 GMT

En el módulo 2 hubo tres clases:

“Introducción al estándar HL7 FHIR” por César Galindo,
“HL7 FHIR Principios y Fundamentos” por Alejandro Medina.
“Recursos” por José María Andrade.

Aquí dejo los apuntes que tomé de ambas clases.

Clase 1: Introducción al estándar HL7 FHIR

Hay mucho entusiasmo con respecto a HL7 lo que ha llevado a que sea muy utilizado en el último tiempo.

¿Qué es FHIR?

FHIR es un estándar para el intercambio de datos de salud. Fue creado por HL7, una organización sin fines de lucro que desarrolla estándares sintácticos desde 1987.

Aunque si le preguntas a uno de sus creadores, te responderá algo como “(FHIR) no es un estándar, es una comunidad que convive para facilitar el intercambio de datos en salud, usando tecnologías web”.

Esto de “comunidad” no se lo toman a la ligera. Hay muchos espacios digitales donde las personas pueden ser parte de FHIR, entre ellos: la documentación, chat, blogs y foro.

Ok, volviendo a las definiciones… FHIR es el acrónimo de Fast, Healthcare, Interoperability, Resources, lo que significa:

Fast: implementación es más rápida. Poner en marcha un sistema interoperable con FHIR es más rápido comparado con otros estándares como HL7 v2.
Healthcare: es un estándar hecho para salud. Puede ser usado para otras cosas pero no tiene mucho sentido hacerlo.
Interoperability: creado para intercambiar información entre 2 o más sistemas.
Resources: utiliza una arquitectura de alta conectividad de la WEB llamada “REST”, la cual se basa en “recursos”.

¿Por qué es importante FHIR?

FHIR es el “caballo de batalla” de HL7, lo que significa que hoy en día es el estándar por defecto a utilizar para proyectos de interoperabilidad en salud.

Hay algunas acciones de la organización HL7 que dan cuenta de esto:

El objetivo de FHIR es que sea un estándar de uso global.
Hay un “FHIR Accelerator” que te ayuda a implementar proyectos de interoperabilidad con FHIR asesorados por HL7 internacional.
El logo de HL7 cambió a uno muy parecido a FHIR 😉.

La historia de FHIR

El mundo de la tecnología avanzó mucho durante la primera década del 2000. Para el año 2011, había una alta conectividad en el mundo de la tecnología, mucha información a procesar (big data), avances en genómica.

Esto hizo que los estándares de esos tiempos (como HL7 v2) fueran quedándose cortos, dejaron de ser coherentes con este nuevo mundo tecnológico.

Así que un grupo de personas expertas en disponibilidad web se juntaron y crearon el primer borrador (“first draft”) de lo que sería FHIR (esto en el año 2011). Fue bien aceptado por la comunidad.

Un timeline de lo que fue ocurriendo:

2011: primer borrador de FHIR
2014: DSTU
2015: DSTU2 (muy usado)
2017: STU3 (usado en USA)
2018: R4 primera normativa
2019: R4 segunda normativa
2022: R5

Algunas definiciones útiles para entender esto:

DSTU: draft standards for trial use. Significa que la especificación no está considerada como completa o no está suficientemente revisada para que sea segura de implementar.
STU: standard for trial use. Significa que ha sido revisado y es considerado seguro para usarlo. Ha sido sometido a votación y es considerado como estándar oficial. Sin embargo, aún no ha tenido un uso generalizado en producción en todo el espectro de entornos en los que está destinado.
Normativa: quiere decir que en el tiempo una estructura de intercambio de datos definida va a cambiar muy poco, podemos usarla con confianza.

Nota: hay más información sobre el nivel de madurez aquí.

Hay que considerar que cuando hablamos de que FHIR es normativa, realmente nos referimos a que solo parte de FHIR es normativa: FHIR trabaja con recursos. Solo algunos recursos son normativos. Hay algunos que no lo son y están lejos de serlo.

¿Qué pasa si trabajo con recursos fuera de la normativa? Es arriesgado, ya que con el tiempo la estructura de intercambio de datos puede cambiar, lo que significa que la implementación construida sobre esto quedará obsoleta y tendrá que ser actualizado.

Así que la normativa es relativa dependiendo de los recursos que nos estemos refiriendo. En R4 los recursos normativos son los más básicos.

Describiendo FHIR

Para describir FHIR, es útil saber un poco de los estándares que lo preceden:

HL7 versión 2: es muy usado, pero tiene 2 desventajas. La primera, es que es estructurado pero con mucho rango de libertad (fácil de romper). La segunda, que es poco amigable con la lógica semántica para casos de uso en salud.
HL7 versión 3: la idea era mejorar la narrativa semántica para que fuera altamente computable. Es muy bueno para documentos clínicos, pero fue un fracaso porque era muy difícil de utilizar.
CDA: nació con la versión 3, es bueno para contar historias de un evento particular de un paciente, lo cual lo hace ideal para documentos clínicos.
CCOW: para documento clínicos de uso particular.

Luego FHIR viene a usar lo mejor de cada uno de estos estándares, para así ser EL estándar de intercambio de datos en salud en contextos diversos. Lo que se busca con FHIR es:

Combinar lo mejor de los estándares en uso.
Aplicar aprendizajes de mensajería V2, V3 y CDA.
Aplicar tecnología web moderna.
Busca mejorar la capacidad de implementación.

Fundamentos de FHIR

FHIR está diseñado específicamente para la WEB, basado en una arquitectura (conjunto de reglas) que reina sobre la web, la cual se llama “REST”.

REST, o REpresentational State Transfer, es un estilo arquitectónico para proporcionar estándares entre sistemas informáticos en la web, lo que facilita la comunicación entre los sistemas — Fuente

En REST, la unidad básica de información (mínima información que se puede intercambiar) se llama “recurso”. Estos recursos en FHIR están preconfigurados para salud. Es por eso que podrás ver un recurso para paciente, otro para profesional de la salud, etc.

Piensa en los recursos como “formularios” de papel que reflejan diferentes tipos de información clínica y administrativa que se pueden capturar y compartir. La especificación FHIR define una “plantilla de formulario” genérica para cada tipo de información clínica, es decir, una para alergias, una para recetas, una para referencias, etc. — (Fuente)

Una “API FHIR” es un servicio web que me ofrece información usando el estándar FHIR. Puedes usar esta “API” para crear aplicaciones sobre la misma (reutilización).

Por ejemplo, Google Maps ofrece una API que me permite crear distintos tipos de aplicaciones, tales como Uber, Rappi, entre otros.

Así que un servicio que ofrece una API FHIR me servirá para crear aplicaciones en el área de salud.

Un API es una interfaz que define cómo hacer la interacción entre distintos sistemas. Un API REST es una arquitectura particular que utiliza las reglas “REST”. La mayoría de los sistemas web utilizan esta arquitectura, lo cual facilita el trabajo para los implementadores que ya están acostumbrado a su utilización.

Para los estándares antiguos, existía un problema de contextualización de la información. Esto ya no ocurre en FHIR porque los recursos están vinculados: puedes crear documentos clínicos gracias a los vínculos.

FHIR te proveé una base que está diseñado para cubrir el 80% de los casos de uso. El 20% depende de cada caso (de las reglas de negocio particulares) y estas se pueden implementar gracias a “extensiones”. Es decir, podemos construir sobre FHIR en vez de hacer todo de 0.

¿Por qué FHIR?

FHIR fue hecho para implementadores.
Cuando haces desarrollos, la dificultad siempre existe. La pregunta es, ¿dónde movemos la dificultad? (teorema de Graham Grieve),
Es fácil de implementar. En promedio, implementar con HL7v2 y CDA tomaba 1 año y medio, mientras que con FHIR son solo 6 meses.
Tiene posibilidad de “mapeo” a otros formatos. Es decir, es fácil transformar de FHIR a V2 o CDA.
Mejor capacidad de comunicar información.
Costo de implementación bajos (500USD). Esto es considerando solo costo de diseño y costo del sistema base.

El mundo FHIR

En la página web puedes encontrar todos los recursos.
Cada día hay más herramientas. Ejemplo: SMART on FHIR
Todo se publica. Hay guías de implementación ya publicadas para distintos casos de uso.
Muchas librerías (gratuitas) que implementadores pueden utilizar.

Preguntas de la clase

¿Qué es una guía de implementación? (esta la hice en clases): “si quiere hacer esto, siga estas reglas”. Son guías que definen reglas basadas en ciertos casos de uso de la vida real. Una parte es “diseño” (cómo se van a comunicar) y otra es “desarrollo” (implementar apps que se van a conectar).
¿Quién crea las extensiones? Una extensión es para guardar información adicional importante para nuestro caso de uso que queda dentro del 20% que no cubre FHIR. Un ejemplo en Chile es guardar si un paciente es GES o no. No hay regulación sobre esto, pero está el capítulo de HL7, y además hay un listado de extensiones disponibles en el sitio de FHIR.

Una pregunta extra que me surgió mientras hacía estos apuntes:

¿Qué es SMART? Entiendo que es un estándar para hacer aplicaciones que se puedan conectar a distintas fuentes de información. Es decir, podría crear una APP de ficha electrónica para el Hospital Salvador y usar exactamente la misma APP (sin rescribir código) para que la clínica Alemana la utilice. Aquí hay más información.

Clase 2: HL7 FHIR — Principios y fundamentos

Esta clase es más teórica que la anterior, y dieron detalles específicos del estándar.

Alejandro nos enseñó a navegar por la página de FHIR, la cual es https://www.hl7.org/fhir/

La organización de la documentación está distribuida en 5 puntos:

Nivel 1: Framework base.
Nivel 2: Apoyo a la implementación.
Nivel 3: relación de recursos FHIR y conceptos del ecosistema real.
Nivel 4: registro e intercambio de datos de procesos clínicos.
Nivel 5: generación de conocimientos con datos clínicos.

Nivel 1

Cada parte de la documentación tiene un “banner” como este:

Que indica quién trabaja, el estado y la seguridad. También indica si es normativo o no.

Por ejemplo, el de la imagen, dice que es información “Normativa”, lo que quiere decir que ha sido probado y que no presentará grandes cambios a futuro.

Cada recurso tiene un nivel de madurez. Los distintos niveles puedes verlos aquí (esto es un nivel de madurez a nivel de recurso solamente).

Tipos de datos: (documentación), hay unos tipos de datos “primitivos”, y hay datos de propósito general que son datos compuestos de elementos primitivos.

Elemento base: (documentación) de aquí se derivan todos los tipos de datos. Es decir, todos los tipos de datos tendrán un identificador (id) y se le podrán asignar extensiones (extension).

Recurso base: (documentación) todo recurso definido en FHIR se compone del recurso base. El recurso base tiene un identificador (id), metadata (meta), un conjunto de reglas (implicitRules) y un lenguaje (language).

Extensiones: (documentación) es un tipo de dato que nos permite implementar aquellas cosas que están dentro del 20% que no nos entrega FHIR. Recordar la regla 80/20 que dice que el 80% lo entrega FHIR, y el 20% depende de cada implementación.

Perfiles: (documentación) es el producto de la formalización de una implementación. Pasa que FHIR crea una plataforma común que permite diferentes implementaciones, en consecuencia, usualmente se requiere modificaciones para adaptar a distintos contextos de uso. Estas adaptaciones o modificaciones se especifican en un perfil. Son la base de las guías de implementación.

Formatos: (documentación) para transmitir la información (entre servidores) se utilizan los formatos JSON y XML (ambos normativos). Hay otros formatos pero que todavía no son normativos (como RDF y ND-JSON).

Nivel 2

Elementos que tienen que ver con el apoyo a la implementación.

Soporte: (documentación) descargas para herramientas, versiones, casos de uso (para orientar), librerías de desarrollo, servidores públicos, herramientas de testing.

Seguridad y privacidad: (documentación) recursos para dejar huellas, recursos de auditoría, se puede hacer trazabilidad.

Conformidad: (documentación) todo lo que puede hacer y las operaciones que soporta.

Terminología: (documentación) cómo implementar un servidor terminológico.

Mecanismo de intercambio: (documentación) API Rest, mensajes, documentos, SOA, base de datos.

Nivel 3

Elementos relacionados con conceptos reales (documentación)

Casos de uso: algunos ejemplos como registro de paciente y actividades clínicas.

Nivel 4

Tiene que ver con procesos (clínicos, diagnóstico, medicamentos, flujo de trabajo, financieros, etc).

Nivel 5

Tiene poca evidencia del uso que se está dando. Son recursos que cambian súper rápido (documentación).

Todos estos recursos tienen que ver con la generación de conocimiento. Compartir, evaluar, indicadores, etc.

Preguntas de la clase

Especificación es distinto a implementación. Todo lo que vimos en la clase es sobre la especificación, es una guía y un conjunto de reglas. Si queremos tener nuestro servidor que cumpla con la especificación FHIR, hay que programarlo o utilizar algo ya existente. Hay código open source (libre y gratis) que podemos usar para crear nuestro servidor, no hay que reinventar la rueda. Un ejemplo es HAPI FHIR (Java).
¿Cómo asegurarnos que se utilicen bien los recursos? la documentación tiene un contexto de uso para cada recurso. Pero siempre va a depender de la interpretación y del caso de uso que estemos implementando.
El perfil es un derivado de la especificación. Uno agrega cosas, no elimina.
Es posible basarse en otras guías para implementar las nuestras. En https://simplifier.net/ hay muchas guías de implementación publicadas.

Clase 3: Recursos

¿Qué es un recurso?

Es una entidad para facilitar el intercambio de datos en salud, tanto en ámbito clínico como administrativo.

Características:

Tienen URL definida.
Tiene una versión.
Derivan de DomainResource
No es posible definir nuestros recursos. Si queremos hacer modificaciones, debemos perfilar.
Podemos agrupar recursos con Bundle.
En su estructura se define el tipo de Recurso.

Estructura de un recurso

Tiene estructura de árbol.
Los datos importantes se encuentran en la raíz.
Cada dato tiene:
- Cardinalidad: 1..1 (el campo siempre tiene que estar presente y debe ser solo 1), 0..1 (el campo puede estar ausente, y de existir, debe ser solo 1), 0..* (el campo puede estar ausente, y de existir, puede ser varios datos)
- Tipo de campo
- Descripción y restricciones
- Banderas:
- ?! no puede ser modificado
- S debe ser soportado
- Σ parte del resumen y operaciones especiales
- I restricciones
- NE sin restricciones
- TU está en pruebas
- N es normativo
- D está en borrador (draft)

Representación de un recurso

Existen dos representaciones normativas: JSON y XML

JSON application/json+fhir
XML application/xml+fhir

Estos formatos son muy usados en plataformas web. Son de fácil lectura e interpretación tanto para humanos como para sistemas informáticos.

Puedes ver un ejemplo de un recurso de paciente en JSON aquí, y en XML aquí.

Los atributos importantes son:

id, es el ID del recurso (generalmente es autogenerado por los sistemas informáticos).
metadata, tiene información de la versión, actualización y un tag/perfil.
narrative, es un HTML con el resumen del recurso. Es importante, ya que si por alguna razón un sistema que utiliza este recurso está limitado a las consultas que realiza, puede mostrar lo guardado en este dato para desplegar la información importante.

Organización de los recursos

Los recursos están organizados por categoría y módulo.

Cada recurso tiene una estructura parecida:

Descripción
Alcance y usos
Límites y relaciones
Cuerpo del recurso
Enlaces terminológicos
Restricciones
Parámetros de búsqueda
Operaciones
Conversiones

Por ejemplo, revisa el recurso Paciente

¿Qué es un perfil?

Un perfil es cuando usamos un recurso en un contexto particular.

Por ejemplo, en Chile, el perfil Chileno de pacientes nos podría hacer agregar un campo (extensión) o un identificador de RUT.

Preguntas en clases

Nota: quizás no apunté todas las preguntas

¿Podemos hacer cambios en los recursos?

Podemos definir reglas nuevas. Para hacer estos cambios, haces un perfil (formalización de los cambios) y documentas su uso mediante una guía de implementación.

Se pueden hacer muchos cambios, hay que tener en cuenta los flags (banderas) cuando hacemos cambios, ya que si rompemos la regla, rompemos el estándar.

¿Con GET obtengo toda la data del paciente?

Obtienes la información definida en el recurso de Paciente. Las relaciones con otros recursos (por ejemplo, encuentros) no vienen aquí.

Interoperabilidad, el contexto de aplicación de HL7 FHIR

Nicolás Gómez — Mon, 26 Apr 2021 16:00:00 GMT

¿Qué es la interoperabilidad?

La interoperabilidad es la capacidad de 2 o más sistemas de intercambiar y utilizar información entre ellos.

Una definición más formal:

Interoperabilidad es la comunicación entre diferentes tecnologías y diferentes aplicaciones de software, que permite el intercambio de datos en forma precisa, efectiva y consistente, y que permite el uso de la información intercambiada.

Notas:

Desde el punto de vista más técnico, un desarrollador web es experto en interoperabilidad, ya que día a día usa o crea estos “puentes” de comunicación entre aplicaciones. Esto no significa que sea experto de interoperabilidad en salud, donde hay estándares y protocolos específicos que hay que aprender.
Tenemos un post que habla sobre interoperabilidad específicamente en salud.

¿Cuáles son los requerimientos para que un sistema sea interoperable?

Poder intercambiar información (interoperabilidad sintáctica)
Utilizar la información intercambiada (interoperabilidad semántica)
Definir reglas de negocio que permitan comprender qué información y qué gatillará dicho intercambio (interoperabilidad de negocio). Es importante saber los procesos que generan los datos que estamos utilizando.

¿Qué es la “Interoperabilidad Absoluta”?

La interoperabilidad es o no es, no hay grados de interoperabilidad.

¿Por qué son importantes los estándares en la interoperabilidad?

Los equipos de informática tienen que crear las “interfaces” de comunicación entre los distintos sistemas. Pueden ponerse de acuerdo y crear “interfaces” adhoc, pero con el tiempo es difícil y costoso de mantener.

La cantidad de interfaces requeridas aumenta en forma cuadrática dependiendo del número de sistemas: nº interfaces = n(n-1)/2, donde (n = cantidad de sistemas).

Como en salud tenemos muchas instituciones y organizaciones que deben interoperar, es importante hacer que la forma en que se comunican sea estándar.

El beneficio de esto es que evitamos crear interfaces adhoc que hay que mantener con el tiempo. Tener una interfaz única hace que la cantidad de interfaces requeridas sea lineal con respecto a la cantidad de sistemas involucrados.

Notas:

Todo parte de la base de que en salud es MUY importante que los sistemas interoperen. Por eso nace todo este movimiento de interoperabilidad y de estándares que van más allá de simplemente “construir un API” bien documentada y fácil de usar.
Tenemos un post sobre estándares de interoperabilidad.

¿Cómo le damos significado a la información que intercambiamos?

La interoperabilidad sintáctica nos permite intercambiar información. Pero para poder utilizar esta información, los datos intercambiados deben tener un significado.

Por ejemplo, la idea es que los datos intercambiados signifiquen lo mismo para China que para USA.

En el área de salud, esto no es tan sencillo ya que un mismo concepto médico puede describirse de distintas formas, más allá del idioma.

Así que para lograr darle significado a un dato, le damos una codificación (para lo cual hay estándares de codificación 😉).

¿Cómo nacen los estándares?

Adhoc: un grupo de personas u organizaciones interesadas se ponen de acuerdo. Ejemplo: DICOM, que es un estándar de transmisión de imágenes médicas.
De facto: cuando una empresa domina el mercado y lo crea. Ejemplo: Microsoft.
De juri o mandato: una agencia de gobierno crea un estándar y legisla su uso.
Consenso: un grupo de voluntarios representantes de las partes interesadas en el estándar desarrollan el mismo en forma abierta. Ejemplo: HL7.

¿Qué es HL7?

HL7 es una organización sin fines de lucro que crea estándares para facilitar el intercambio electrónico de información clínica.

Han creado distintos estándares, como por ejemplo:

HL7 v2: estándar de mensajería para el intercambio electrónico de datos de salud.
HL7 v3: estándar de mensajería para el intercambio electrónico de datos de salud basada en el RIM.
HL7 CDA: estándar de arquitectura de documentos clínicos electrónicos.

¿Cómo nace FHIR?

Un poco de contexto:

El estándar más utilizado en el mundo es HL7 v2, el problema es que no es fácil de leer para un clínico.
CDA es muy robusto pero solo es para intercambiar documentación clínica.
Luego surgió HL7 v3, el cual no fue muy popular debido a la complejidad de adoptar.

El problema es que las tecnologías evolucionaron más rápido que los estándares. Nos movimos del mundo offline al mundo online, de desktop a mobile, de software a aplicaciones, de servidores al mundo cloud, de sistemas cerrados a APIs abiertas…

REST marca los cimientos de FHIR (Fast Healthcare Interoperability Resources), permitiendo definir el mundo de la salud en recursos que puedan ser entendidos por clínicos y por informáticos.

Algunos beneficios:

Más fácil de hacer aplicaciones.
Curva de aprendizaje menor.
Facilita la implementación.

Además soporta distintos tipos de arquitecturas:

RESTful API
Mensajes
Documentos
Servicios / SOA
Bases de datos / Persistencia

Y está siendo muy adoptado en la industria.

¿Dónde podemos encontrar ejemplos y proyectos que usan HL7 FHIR?

En la página simplifier podemos encontrar la documentación de proyectos a nivel global.

En la página existen 80 proyectos en Chile.

Preguntas y respuestas

En la sesión presencial surgieron las siguientes preguntas:

¿CDA o FHIR?

CDA es solo para intercambiar documentación clínica, y con FHIR también es posible hacerlo.

No hay una respuesta correcta, pero Sergio (profesor) recomienda FHIR porque va de la mano con el avance tecnológico.

¿Vale la pena aprender HL7 v2?

Grandes compañías como Google, Microsoft, Apple y Oracle comenzaron a apostar con FHIR. Esto marca las pautas a futuro, y hará que el mercado se mueva a FHIR.

HL7 v2 hoy en día es más legado. V2 está probado, es rápido y es liviano. Incluso hay algunas tecnologías (como en laboratorios) donde todo lo exportan a HL7v2. Así que al final del día siempre va a depender del contexto.

Sin embargo, Sergio (profesor) recomienda FHIR por las razones antes mencionadas (los grandes están invirtiendo en esto, y además está en sintonía con los avances en tecnología).

¿Existe alguna normativa de parte del MINSAL?

Todavía no hay políticas de país ni de estado que fomenten la interoperabilidad.

¿Por qué usar un estándar baja la cantidad de conexiones?

No baja la cantidad de conexiones. Baja la cantidad de interfaces diferentes. Siempre existirán conexiones, un estándar tú conectas el cómo leen tu data y tu cómo la compartes (cómo escribir y cómo leer).

¿Es obligatorio usar un server FHIR o solo el estándar?

FHIR es un estándar con múltiples implementaciones. Existe un servidor llamado HAPI FHIR, el cual puedes utilizar e instalar.

Así que existen muchas implementaciones en distintos lenguajes (en C, Java, etc). El estándar da la estructura, lo importante es cumplir con el estándar.

Es posible hacerlo de cero, pero existen herramientas creadas que podemos usar (y que son de software libre).

¿Quién está usando FHIR?

Algunas menciones: Araucanía sur, Iquique, El ministerio de salud, UC Christus, el metropolitano sur oriente y La clínica Alemana.

¿Existen casos de éxito de instituciones países que usen FHIR?

Algunos ejemplos:

En Perú, Roche está migrando mucho a guías de implementación de FHIR.
USA y Canada muy de la mano con la tecnología.
Colombia tiene algunos ejemplos con FHIR (algunas clínicas).
Argentina.

Apuntes del curso HL7 FHIR Principios y Fundamentos

Nicolás Gómez — Mon, 26 Apr 2021 14:00:00 GMT

Aquí encontrarás mis apuntes del curso HL7® FHIR®: Principios y Fundamentos

Creando Apposito

Nicolás Gómez — Thu, 22 Apr 2021 14:00:00 GMT

Apposito una aplicación que profesionales de la salud pueden utilizar para hacer seguimiento de heridas de sus pacientes.

Con Eliana decidimos crear este servicio en octubre del 2020. Maduramos la idea hasta que en diciembre del mismo año comenzamos a construirla.

En este post hablaré sobre el proceso de construcción de Apposito. Intentaré ser lo más sincero posible, sin embellecer cosas.

Prólogo: La ética digital

Lo que nos motivó a crear Apposito fueron las ganas de traer al mundo un producto que fuera útil y que nos sintiéramos orgulloso de crearlo. El camino también importaba, pues tenía que ser dentro del ámbito de la salud y que nos sirviera para aprender lo más posible.

Útil + orgullosos + ámbito salud desechó completamente la famosa frase “Si no te avergüenza la primera versión de tu producto, lo lanzaste muy tarde”.

Sentiríamos vergüenza del producto si este fuera en contra de la dignidad humana. Y no estábamos dispuestos a tranzar en eso.

La premisa de construir tecnología con ética digital y respetando la dignidad de los usuarios y pacientes fue nuestra máxima.

¿En qué influye este como programador? En asegurarte de que todos los servicios y tecnologías que usas cumplen con un estándar mínimo de ética digital. Si dices que tu producto o empresa “respeta la privacidad” de tus usuarios, ser consecuente. Un ejemplo de estas inconsistencias que veo día a día:

Utilizar herramienta de seguimiento y cookies como Google Analytics. Es gratis y fácil de usar, pero no es ético. Google lo utiliza para obtener la mayor cantidad de información de una persona, así hacerle seguimiento y mostrarle publicidad (más aquí).
Facilitar inicios de sesión con Facebook. Agregar esto a tu aplicación hacen que incluso las personas que no lo utilizan sean trackeadas por Facebook 🤮.
Espiar las bandejas de entrada de tus usuarios con herramientas tipo “Mailchimp” que te dice que usuarios abren tus correos y qué links presionan (este seguimiento se puede deshabilitar).

Está ok si usas estas herramientas. No quiero iniciar una caza de brujas. El problema es cuando las usas y dices “que respetas la privacidad”, pues no es tan cierto.

Con Apposito quisimos hacer las cosas diferentes y nos preocupamos de que todo lo que usáramos estuviera a la par con la ética digital, que en la práctica significa utilizar productos y servicios que cumplan con GDPR e HIPAA. No tenemos la obligación legal de hacerlo, ya que la APP no está en EEUU ni en Europa (todavía).

¿Por qué menciono todo esto? Muchas decisiones que tomamos fue basados en esta filosofía. Por ejemplo, preferimos postergar un lanzamiento inicial para hacer la aplicación más segura introduciendo bloqueo de pantalla por inactividad. Desde el punto de vista más lean ese feature seguramente es desechable, pero desde el cuidado de datos es muy importante.

Construyendo Apposito: diseño y planificación

Con Eli comenzamos a construir Apposito en diciembre 2020.

Primero definimos el contexto, una posible solución e ideas que ayudarían a lograr solucionar la problemática. Todo esto lo documentamos en un archivo en Google Docs, para uso interno. Nada fancy.

Luego hicimos un brainstorming de las funcionalidades que podría tener el software. Para nuestra suerte, Eliana es enfermera y un posible usuario, así que ella supo reducir un listado de ideas choras a lo mínimo desde el punto de vista funcional:

El listado es simple, no tiene ningún formato particular.

Luego Eliana trabajó en un prototipo inicial, pensando en cómo debería ser el flujo de uso de la aplicación:

(Si un UX está leyendo… ¡Lo siento! Improvisamos en esto 🙈)

Y finalmente decidimos una paleta de colores para utilizarlo al momento de construir la aplicación y en elementos de marketing:

Metodología de trabajo

Ya con una idea clara de lo que queríamos lograr y los flujos que queríamos implementar, lo que sigue es implementar la solución.

Mantuvimos una mentalidad lean a lo largo del proyecto. La idea era crear algo útil, basado en las funcionalidades que definimos como importantes, que nos tomara la menor cantidad de tiempo y estuviera dentro de marcos éticos en salud.

Esto significó priorizar funcionalidades que al principio no nos parecía tan importantes (ej: bloqueo de la APP por inactividad) pero a la vez desechamos otras (ej: edición y eliminación de datos). La pregunta “¿cómo hacemos esto más simple?” nos fue de mucha ayuda.

Organizamos el trabajo con la metodología Kanban, principalmente porque teníamos un conjunto de tareas bien definido y porque íbamos a trabajar a tiempo parcial en el proyecto.

Utilizamos Trello, ya que ambos teníamos experiencia de trabajo con esta herramienta.

Nuestro flujo de trabajo fue muy estándar y consistió en las siguientes etapas:

TODO: lo que queda por hacer, de mayor prioridad a menor prioridad.
In-progress: en lo que estamos trabajando. Sirve para comunicar al equipo (y a ti mismo) en qué se está trabajando.
In-review: lo que está listo pero no revisado por otra persona.
Done: lo que está listo y revisado.

Adicionalmente agregamos una columna de “Nice to have” que son ideas o tareas que sería bueno hacer pero que no son prioritarias por ahora.

Si bien solo somos 2 personas que más encima trabajamos en el mismo home office, mantener este orden y estructura ayuda muchísimo. Por un lado te sirve para visualizar cómo va el proyecto y en qué va avanzando cada uno, sin tener que “molestar” al otro. Además, como tenemos otros proyectos, es más fácil volver a trabajar en Apposito con este orden. Simplemente continúas con lo que está en “In Progress” o tomas la primera tarea de “TODO”.

Con respecto a las tareas de producto que consistían en implementar funcionalidades (es decir, programar) las trabajamos con Gitflow. Es una forma de hacer cambios en el código muy flexible y muy utilizada en la industria del software.

El código lo alojamos en GitHub pues ambos estamos muy familiarizados con este servicio.

Finalmente, trabajamos con revisión de a pares. Eliana no tenía experiencia en esto, así que también cumplía con el propósito de que entrenara esta habilidad.

Tecnologías Utilizadas

Antes de pasar a las tecnologías, quiero explicar decisiones más a alto nivel:

¿Por qué tiene que ser una APP?
¿Por qué tenemos que guardar los datos en la nube y no en el dispositivo?

¿Por qué una APP?

Parece obvio que esto debería ser una APP. ¿Pero por qué?

Para documentar la evolución de una herida con imágenes necesitas una cámara. Los celulares tienen cámara, y asumimos que un profesional de la salud que cuida heridas tiene celular.

Así que el software tiene que ser accesible mediante un celular. Esto se puede lograr de dos formas: con una aplicación móvil o con una página web.

Decidimos que fuera una aplicación para tener full soporte de hardware, ya que en web el acceso a funciones del hardware es limitado. Con hardware me refiero a cosas como la cámara, lector biométrico y almacenamiento seguro.

¿Por qué guardar datos en la nube?

¿Dónde guardamos la información?

Puede ser en el dispositivo, puede ser en la nube.

Descartamos guardar en el dispositivo porque:

El cuidado de una herida puede pasar por varios profesionales. Es decir, tiene que haber una forma de compartir heridas con tu equipo. Guardar la información en la nube habilita esta opción.
La información debe sobrevivir en caso de hurto, extravío o cambio de dispositivo. Además, debe poder ser accesible solo a través de la aplicación (para evitar que alguien con acceso indebido vea los datos).
A futuro nos gustaría que nuestra solución fuese interoperable.

Para lograr estos objetivos, creemos que guardar la información en la “nube” es la forma correcta.

Nuestro stack tecnológico

Uno de nuestros objetivos era “aprender lo más posible” mientras desarrollábamos la aplicación. Sin embargo, desde el punto de vista tecnológico, nos fuimos por un camino conocido.

Elegimos herramientas que nos fueran familiares: React Native y Firebase.

¿Por qué React Native?

React Native (RN) es una tecnología que te permite escribir aplicaciones multiplataforma para iPhone y Android, utilizando una herramienta llamada “React”.

Esta fue una decisión fácil porque yo llevo 3 años trabajando con RN y Eli maneja React súper bien. Si sabes React, con un poco de ayuda RN no es tan difícil. De hecho, Héctor Salas, estudiante de full-stack en 4Geeks Academy, nos aporto con un granito de arena:

Comenzamos desarrollando la APP con Expo, un framework que te permite crear aplicaciones en RN de manera más fácil y rápida.

Debido a que Expo no tiene soporte de Firebase, tuvimos que “eyectar” Expo (mayor complejidad a cambio de más libertad). Sin embargo, partir con Expo nos permitió iterar rápido en un comienzo (implementamos todas las vistas con Expo).

¿Por qué Firebase?

Firebase es una tecnología de Google que permite guardar datos en la nube de manera simple y segura. Lo utilizamos como base de datos (Firestore) y para guardar las fotos de las heridas (Cloud Storage).

Si bien ambos teníamos experiencias previas con el servicio (en nuestros trabajos anteriores), la decisión no fue tan simple.

Lo que nos hacía dudar era el marco regulatorio. De mi trabajo anterior, recordaba que se descartó Firebase porque no cumplía con HIPAA. HIPAA es una ley de USA creada para modernizar el flujo de información de salud de forma segura, si queremos expandirnos es importante usar servicios que cumplan la norma.

Por otro lado, durante la mayor parte de mi carrera he utilizado un framework llamado Ruby on Rails (RoR). Más encima trabajé en un desarrollo que lo utilizaba y que cumplía con HIPAA. ¿Qué mejor?

Entonces estaba en la disyuntiva: ¿lo hacemos con Ruby on Rails (RoR)? (más lento, soy experto pero Eli no) ¿lo hacemos con Firebase? (más rápido y ambos tenemos conocimientos).

Uno de los factores clave fue el tiempo. Durante enero avanzamos muy poco en el proyecto debido a vacaciones y otros proyectos.

Así que entre el factor tiempo y factor conocimientos, la opción obvia era Firebase. Pues nos permitía avanzar más rápido y es una tecnología que ambos manejamos.

Luego descubrí que Firebase sí cumple HIPAAA 🎉 . Si bien no son todos los servicios, nos preocupamos de usar solo servicios que sí estuviesen cubiertos.

Si sabes sobre salud digital, quizás te estés preguntando por qué no hicimos que nuestro servicio fuese interoperable, utilizando por ejemplo FHIR. La verdad es que lo consideramos, porque algo de experiencia tenemos. Descartamos la opción, a pesar de las recomendaciones, porque sabíamos que no hubiésemos demorado mucho más.

Si bien no usamos HL7, sí nos dimos el trabajo de modelar la solución utilizando recursos de FHIR. Esto nos ayudó a nombrar nuestras colecciones y atributos en Firestore de una forma similar a como lo hacen en FHIR. Esperamos que esta decisión nos ayude a futuro cuando tengamos que hacer una migración o integración.

Lo bueno es que quizás la integración no sea difícil, considerando que FHIR es parte de Cloud Healthcare API de Google Cloud (proveedor que estamos usando).

Desafíos de producto

El tema regulatorio es todo un desafío. Preguntas tales como quién es el dueño de los datos y quién tiene acceso a ellos son importantes de responder.

Si bien nuestra filosofía de crear productos es siempre actuar de buena fe y considerar la ética digital, es importante tener nociones del marco regulatorio.

Respondimos esas preguntas en paralelo a la construcción de la aplicación. Fue una apuesta más o menos segura, ya que conocemos la existencia de aplicaciones similares, incluso creadas en Chile. Solo teníamos que estar seguros.

Todavía tenemos dudas relacionadas, sobre todo como aplican estas preguntas en diferentes países y cómo se relacionan con otras leyes como GDPR e HIPAA.

Todo esto fue considerado en el desarrollo de la aplicación. Por ejemplo:

Antes de solicitar datos, le recordamos al profesional que debe tener el consentimiento informado del paciente o del tutor.
Bloquear la pantalla luego de inactividad para agregar medidas de prevención contra que alguien sin consentimiento vea información sensible.
Encriptación de la información guardada (datos, imágenes)

Todas estas cosas agregan fricción y tiempo de desarrollo. Pero es un precio justo que debíamos pagar.

Desafíos técnicos

Dicen que programar en React Native (Expo) es fabuloso, que puedes programar rápido y todo eso. Lo mismo con Firebase. ¿Es realmente así?

Mi respuesta corta es: sí, en general sí. Pero en el día a día te encuentras con problemas.

En React Native tienes que estar dispuesto a pelear con bugs que encontrarás con versiones viejas de Android o con librerías open source.

En Firebase, tienes que pelear con la documentación. Si la miras por encima se ve genial, pero en el día a día, cuando tienes que usarla, resolver problemas y buscar cómo hacer cosas, es un infierno.

En otro post te diré los problemas que tuvimos con ambas tecnologías y cómo los solucionamos.

Desafíos de diseño

No tenemos formación en diseño y no nos asesoramos 😅. Desde los colores al logo todo lo hicimos nosotros.

Eso sí, nos apalancamos con herramientas para crear elementos visuales:

La paleta de colores fue inspirada en una paleta de ColorHunt.
Muchos recursos visuales (tales como el logo, imágenes dentro de la APP o lo que hay en la landing page) las hicimos con Canva.
La landing page la construímos con Webflow.
Para la interfaz de usuario utilizamos UIKitten.
Para el arte de PlayStore y AppStore utilizamos AppMockUp.

Me gustó el resultado. Al menos nuestros testers iniciales así lo consideraron. De todas formas, estoy seguro que es bastante competitiva con respecto a las otras aplicaciones del mercado 😂, pues hice mi investigación.

El resultado

Luego de 144 commits, publicamos la aplicación en App Store y Play Store el 15 de abril.

Publicamos un mes después de lo que originalmente habíamos pensado 😓 pero nos ayudó a refinar más el producto y a probar con más personas.

El futuro

Ya tenemos una versión inicial sólida que usuarios pueden comenzar a usar. Así que próximamente moveremos recursos de desarrollo a distribución.

Sabemos que hay empresas que viven de solucionar la misma problemática. Para algunos emprendedores esto es un problema. Para nosotros no, pues eso significa que existe mercado.

La pregunta a responder es cómo llegamos a ese mercado. Ese es el siguiente desafío.

¿Cómo nace la idea de Apposito?

Eliana Quijada — Wed, 21 Apr 2021 22:00:00 GMT

Apposito es una aplicación que busca ayudar al seguimiento de heridas complejas, creada por nosotros: Codeness. En este post intentaré contar del proceso que seguimos para darle forma a la idea inicial de nuestra aplicación.

El comienzo

En octubre del 2020, comenzamos con las ideas iniciales que finalmente nos llevarían a crear Apposito.

La primera decisión que tomamos fue que queríamos crear una aplicación o servicio en el área de la salud, para así aprovechar mis conocimientos como enfermera.

La segunda decisión fue acerca de los usuarios finales: ¿Queríamos crear algo para pacientes o algo para profesionales?

Optamos por la segunda opción, en primer lugar porque sentíamos que una gran manera de sacarle provecho a mi experiencia como enfermera, era justamente buscando algún “dolor” que yo misma hubiese tenido mientras ejercía la atención clínica. Y al mismo tiempo podía recurrir a mis “contactos” cuando necesitáramos gente que probara nuestra aplicación.

Como nuestra intención era partir con un producto pequeñito, la idea era utilizar todas las herramientas que tuviéramos a mano de forma eficiente y rápida.

Luego venía la siguiente gran pregunta…

¿De qué manera podemos ayudar a los profesionales?

Volviendo a la idea anterior, de querer sacarle el máximo provecho a mi experiencia, y porque no decirlo, una deuda personal, de querer hacer algo que nos ayudara a las enfermeras y enfermeros en particular, comenzó una lluvia de ideas, que terminó siendo una gran lista con un resumen de algunas de las funciones realizadas por las enfermeras y enfermeros tanto en el ámbito clínico, docencia y gestión (visto desde mi experiencia).

Luego, tratamos de enfocar de qué manera podíamos impactar realmente a cualquier enfermero o enfermera que quisiera usar nuestra aplicación, sin importar si trabaja con fichas electrónicas o de papel.

Siempre trabajé en el servicio público y me consta que hay hospitales que con suerte tienen un computador “viejito” para todo el personal de la sala, así que para mí era súper relevante que lo que eligiéramos hacer, funcionara independiente del nivel de tecnología utilizado en cada servicio. Que pudiese trabajar de forma “aislada” si no hay otra opción, pero que al mismo tiempo pudiese interoperar si es que el desarrollo tecnológico de la institución lo permite.

Eso redujo bastante las ideas del momento, pero aún teníamos unas 3 o 4 alternativas que sonaban bien, y lo mejor de todo, que yo sentía que si las hubiese tenido cuando trabajaba en el hospital me habrían ayudado mucho.

Ahí también comente las ideas con algunas otras enfermeras, para saber si percibían las mismas necesidades que yo.

Heridas y curaciones

Una de estas opciones, era el tema de las heridas y curaciones, un área súper transversal, porque tiene su espacio tanto a nivel primario (CESFAM/consultorios) como a nivel terciario (hospitales), pasando por centros especializados específicamente en el tratamiento de las heridas.

Para las enfermeras en general las curaciones son un tema muy importante, ya sea si estamos hablando de curaciones avanzadas de heridas crónicas (como las heridas de pacientes diabéticos, las lesiones por presión, las úlceras varicosas, etc.) o de curaciones asociadas a dispositivos médicos, como por ejemplo las ostomías, o las curaciones de catéteres venosos centrales.

Desde que era estudiante de enfermería y tuve mi primera pasada práctica en un servicio de cirugía, que tengo grabado en la mente todo lo que tenía que evaluar de una herida al realizar una curación:

Estado de los apósitos retirados
Calidad/cantidad del exudado
Estado del lecho de la herida
Tipo y proporción de tejido
Tamaño
Profundidad
Y un largo etcétera…

Pero posteriormente cuando ejercía como profesional, pude ver como los registros muchas veces no reflejaban todo lo que se debía observar (esto se debe a muchos factores, entre ellos el tiempo y/o el espacio para realizar el registro de la curación).

¿Cómo podíamos solucionar el problema?

La respuesta inmediata que uno podría pensar es hacer un sistema de registro detallado, que solicite todos los puntos esenciales mencionados. Sé que hay fichas clínicas que se preocupan de estos detalles, “recordando” al profesional todo lo que debe evaluar.

Pero si volvemos al punto de los centros que aún manejan ficha de papel, pedir un registro detallado aparte del “oficial” que se realiza en la ficha clínica, solo aumentaría la carga del profesional (y debo contarles queridos lectores, que actualmente es muchísimo más común de lo pensado, que en la práctica clínica se tenga que repetir varias veces el mismo proceso de registro).

Y así, surgió la idea de hacer una aplicación que ayudara a realizar el seguimiento de heridas, pero centrada en imágenes, y de alguna manera fortalecer el “registro oficial” de la herida.

Evaluando las aplicaciones existentes

Una vez que la idea tenía más forma, comenzamos a ver las aplicaciones que intentaban solucionar el mismo problema.

Me encontré con distintas aplicaciones, algunas de pago y otras gratuitas. Un par apuntaban al seguimiento de heridas con imágenes, aunque las acompañaban con un registro más complejo con formularios gigantes. Eran pocas las aplicaciones centradas netamente en registro de fotografías.

También pregunté a enfermeras que tuvieran algo de experiencia con el tema de heridas, y al menos ellas no conocían algo que funcionara como lo que yo imaginaba.

Por todo esto, pensé que sería una buena idea continuar con la idea. El hecho de que existieran aplicaciones intentando solucionar el mismo problema, con cantidad decente de descargas y algunas ya cobrando, pese a detalles de usabilidad y comunicación, fue alentador.

Usos prácticos

Mi premisa central para darle valor al uso de fotos está basada en que el recuerdo del estado de la herida es algo subjetivo.

Es muy probable que al momento de ir a registrar la curación realizada, el recuerdo de lo observado ya no sea tan detallado, y mientras más demoramos en realizar ese registro, menos objetiva es nuestra imagen mental.

De manera personal yo pensé principalmente en algunas situaciones en las que una aplicación de seguimiento de heridas me hubiese servido:

Heridas crónicas: Fui interna de un servicio de cirugía de adultos, por lo que gran parte de mi día consistía en realizar curaciones a pacientes con heridas crónicas complicadas que se hospitalizaban para aseos quirúrgicos.

En este caso, si bien uno intentaba realizar un registro lo más completo posible, el evaluar si una herida iba mejorando o empeorando, muchas veces quedaba a criterio de la memoria.

Curación de catéter venoso central: Trabajé un par de años en una sala de Trasplante de Médula, por las características del tratamiento y evolución de los pacientes, desde el momento en que ingresaban se les instalaba un catéter venoso central, que habitualmente permanecía por toda su hospitalización, la que podía durar en promedio unos 30 días.

Además de la importancia que ya tiene el manejo de dispositivos invasivos, en el caso de estos pacientes había riesgos agregados: pasaban por períodos de neutropenía severa (baja de defensas) que los hacía más susceptibles a infecciones. Adicionalmente, a causa de algunos medicamentos su piel se volvía muy sensible, por lo que el retiro constante de los parches que cubren el catéter también generaba lesiones. Todo esto hacía que la curación realizada y la evolución de todo el sitio que rodeaba al catéter fuese de importante seguimiento.

Me hubiese sido muy útil para el seguimiento diario del que tenía que generar reportes, haber tenido un respaldo de imágenes que hiciera objetiva la evolución.

Alta rotación de profesionales: Un punto que a veces dificulta el seguimiento de la evolución de una herida es la rotación de diferentes enfermeras y enfermeros curando al mismo paciente, esto sucede por diferentes factores como los turnos rotativos y la alta tasa de reemplazos. Situación en la que también me parece hubiese sido buena idea tener un registro visual compartido entre todos los profesionales a cargo del paciente.

A estos ejemplos intrahospitalarios también puedo agregar contextos como: los policlínicos de curaciones, los programas de atención domiciliaria, instituciones dedicadas a la investigación o a la formación.

Siguientes pasos

Ya con la decisión tomada y los primeros lineamientos en mente, se venía la parte más técnica: decidir qué tecnologías utilizar y cuáles serían las características que tendría nuestra primera versión.

Nicolás escribió sobre esto en el post “Creando Apposito”.

Tuskas

Nicolás Gómez — Thu, 18 Feb 2021 14:00:00 GMT

¿Es posible automatizar el diagnóstico de cáncer uterino con inteligencia artificial?

Esta pregunta dio origen a TUSKAS (Transfer useful secure knowledge at your services… 😂), un servicio para apoyar y automatizar el diagnóstico de cáncer uterino.

TUSKAS fue el proyecto final de la carrera de “Data Science” en Desafio Latam que realicé junto a mis compañeros Pancho, Rafa, Javier y Cris.

En este post te contaré cómo abordamos el proyecto, y los desafíos con los con los que nos encontramos.

Contexto

Me encantaría decirte que la idea se le ocurrió a uno de nosotros mágicamente mientras dormía, como varias historias de emprendimiento.

La verdad es más simple: teníamos que aplicar lo aprendido durante la carrera en un proyecto. Ya sabíamos que teníamos que usar inteligencia artificial para resolver una problemática. Así definimos muestro martillo.

Llegar al clavo fue parecido: queríamos trabajar con reconocimiento de imágenes. Si bien no es algo que se ve en el curso, nos interesó ir más allá.

Rafa nos había comentado sobre su frustración de nunca haber hecho algo con anatomía patológica… Así que nos pusimos a investigar sobre aplicaciones de IA en el ámbito de salud, y llegamos a algunos papers donde utilizan algoritmos para la detección de cáncer cervicouterino (CCU). Así encontramos el clavo.

Fue un match perfecto. Rafa y Javier llevan años trabajando en salud, Pancho y yo estábamos motivados por los algoritmos y Cris con la optimización de procesos que una solución con IA podía lograr.

Foto del 2019, pre pandemia

El problema

Ya en conocimiento de un problema que podemos atacar con lo aprendido en el curso, nos pusimos de cabeza a investigar más sobre este tipo de cáncer. Javier, el hombre de los contactos, dio con Francisca Correa, doctora del instituto del Cáncer, quién nos orientó en la elaboración del proyecto.

Así llegamos a algunas estadísticas alarmantes (Minsal, 2005), en Chile el cáncer cervicouterino:

es la segunda causa de muerte en la mujer entre 20 y 44 años.
es la principal causa de muerte por cáncer en la mujer entre 20 y 44 años.
es la quinta causa en el grupo entre 45 y 64 años de edad.

La estrategia central para disminuir la mortalidad de este cáncer es la detección temprana mediante la toma de Papanicolau (PAP).

El PAP no es un examen que te haces una vez y te olvidas. Es un examen que las mujeres tienen que hacerse cada 3 años en el rango etario de 25 y 64 años.

Pese a los esfuerzos para aumentar la cobertura del tamizaje, la mortalidad sigue siendo alta. Nosotros creemos que esto se debe a dos factores: la escasez de especialistas y errores de diagnósticos.

Estoy convencido de que un asistente que ayude al especialista a analizar una muestra de PAP disminuirá la mortalidad del CCU, ya que lo ayudará a hacer su trabajo de forma más eficiente y además podría brindarle una segunda opinión, disminuyendo posible errores de diagnósticos.

Y no solo eso, es económicamente viable. En salud pública, los servicios clínicos de anatomía patológica no logran cubrir la demanda de estudios, y recurren a la compra al extrasistema, debido a la falta de recurso humano, insumos o equipamiento.

La solución: TUSKITA

Debido a todo lo anterior, creamos a TUSKITA, un algoritmo que permite detectar anormalidades en células de un examen PAP, el cual fue construido con Machine Learning, específicamente usando Deep Learning.

Si estos conceptos son chino para ti, puedes ver este post que tiene definiciones de IA, Machine Learning, entre otros.

¿Cómo creamos TUSKITA?

1) Definición del problema

Lo primero fue definir bien el problema: dada una imagen de una célula de un examen PAP, clasificarla como NORMAL o ANORMAL.

O en otras palabras, responder a la pregunta “¿esta célula es anormal?”

2) Obtención de datos y preprocesamiento

Machine Learning es decirle al computador “toma estas imágenes, estas son anormales, estas otras son normales. Por favor, aprende a identificarlas”. Así que sin los datos (imágenes de células clasificadas) estábamos fritos.

Lo bueno es que ya sabíamos de la existencia de datos, pues hay papers que abordan el mismo problema (ejemplo: DeepPap, Cervical cytology intelligent diagnosis).

Usamos el dataset que utilizan en la literatura: Smear2005 del Herlev University Hospital.

El dataset consiste en 917 imágenes, donde 242 son células normales (~26%) y 675 son anormales (~74%). Esto implica que las categorías están “desbalanceadas”, pues la “anormal” es casi 3 veces la “normal”.

Aquí hay dos problemas:

Hay pocas células normales, por lo que el clasificador podría estar más sesgado hacia las anormales (problema de desbalanceo de clases).
Muy pocos ejemplos para que el clasificador aprenda a distinguir entre normales y anormales.

El primer problema lo abordamos mediante distintas técnicas (ej. “Data augmentation”, “Data Stratification”). Finalmente nos quedamos con la sugerencia que nos dio nuestra profesora Andrea Villaroel, que fue balancear los datos de entrenamiento. Así que alimentamos a Tuskita con 50% anormales y 50% normales, elegidas de forma aleatoria.

El segundo problema lo abordamos de igual forma que lo hicieron en DeepPap, con una técnica llamada “Transfer Learning”. En palabras simples, le enseñamos a nuestro clasificador a identificar distintos objetos de conocimiento general en una imagen (utilizando un dataset GIGANTE llamado ImageNet), y sobre el conocimiento adquirido, le enseñamos a clasificar las células.

3) El algoritmo

Al igual que en DeepPap, utilizamos el modelo VGG16 para desarrollar nuestro clasificador. Probamos otros pero este fue el que mejor nos funcionó.

Aquí nos dimos cuenta que sabiendo las bases, es posible comenzar a aplicar otros algoritmos que ya están hechos y adaptarlos a tus necesidades.

A modo de ejemplo, aquí utilizan el mismo modelo para clasificar perros 🐶 y gatos 🐱. La verdad que adaptar eso a clasificación de células no es muy distinto 🙊.

Para aprender las bases de Deep Learning, vi los primeros videos de la especialización de Deep Learning en coursera (usé los 7 días gratuitos).

Resultados de TUSKITA

El peor error que podemos cometer es indicar que una célula anormal es normal. Por ende, la métrica más relevante es el recall sobre las anormales (en la imagen aparece como cancer), el cual es 89%. Esto quiere decir que somos capaces de detectar el 89% de todas las células anormales. Not bad.

Si bien estamos lejos del estado del arte (98%), los resultados son esperanzadores y creo que son lo suficientemente buenos para construir un asistente virtual.

Usos y Aplicaciones de TUSKITA

Una parte del problema es desarrollar el algoritmo, pero ¿cómo lo utilizamos en la práctica?

Por eso creamos TUSKAS, un servicio accesible mediante Internet al cual le envías una foto de una célula y te dice si es normal o anormal:

De esta forma, cualquier dispositivo conectado a Internet, podría enviar una imagen para ser analizada por TUSKITA.

Para los más computines 🤓, esto significa que creamos una API. Cuando tu modelo está en python, puedes crear una API utilizando Flask e importarlo fácilmente.

Con TUSKAS, creé una mini aplicación llamada Tu segunda opinión donde subes una imagen y te dice si la célula es normal o anormal. Puedes ver una demostración en el siguiente video:

Estado actual del proyecto y desafíos a futuro

La verdad es que ninguno de los 5 siguió impulsando el proyecto 😅, por lo que el estado actual es de prototipo. Eso sí, todavía tenemos el código fuente, listo para continuar 🚀

El desafío a continuación es mejorar TUSKAS para que sea capaz de recibir un PAP completo en vez de una imagen de célula. Para esto, tenemos que crear un nuevo clasificador (¿TUSKOTA?) que analice un PAP y localice cada células. Luego, usando Tuskita sobre cada célula localizada, podremos saber el estado general del PAP.

Otro desafío no menor es seguir mejorando los resultados del algoritmo, ya que sabemos que hay espacio para hacerlo.

Y la pregunta más importante: ¿tendrá cabida una solución así en el estado actual de tecnología en Chile?

Espero que sí.

Informática para no informáticos #3

Nicolás Gómez — Thu, 28 Jan 2021 14:00:00 GMT

¿Te suenan los conceptos de “Inteligencia artificial”, “Blockchain” e “IoT”?

Seguramente los has escuchado, ya que son conceptos de tecnología muy de moda y que generalmente van acompañado de mucho marketing.

En este post, voy a explicar estos conceptos y otros más desde el punto de vista del ámbito de salud.

Para reírse un poquito… en “La cocina de la Salud digital” tenemos la receta perfecta para venderle proyectos al ecosistema de innovación en salud (👀 léase con ironía):

¿Qué son los “Algoritmos”?

Partimos con la definición de “Algoritmo”, ya que es un concepto que nos ayudará a entender mejor la Inteligencia Artificial:

Los algoritmos son reglas que muestran el paso a paso necesario para la realización de un problema. A través de una secuencia lógica, definida y finita de instrucciones, ellos determinan el camino a seguir para ejecutar una tarea. (Fuente).

Cuando un programador escribe un programa, lo que está haciendo es construir un algoritmo.

Te daré dos ejemplos por si no te ha quedado muy clara la definición.

El primer ejemplo, una receta para hacer huevo frito lo podríamos ver como un algoritmo:

Imagen extraida de "Programación: etapas de la programación"

El segundo ejemplo, en el ámbito de salud, tenemos algunos algoritmos de diagnóstico:

Imagen extraida de guía "Algoritmo dolor torácico" del MINSAL

¿Qué es la “Inteligencia Artificial”?

Los principales libros de texto de IA definen el campo como el estudio de los “agentes inteligentes”: cualquier sistema que perciba su entorno y tome acciones que maximicen sus posibilidades de lograr sus objetivos Fuente

Esta es una definición amplia, pero mucho más aterrizada de lo que suele ver en las noticias.

Un ejemplo es una “aspiradora robot”, que son capaces de limpiar el suelo de tu casa, sin saber de antemano (al momento de comprar) cómo están distribuidos los cuartos o tus muebles.

Existen distintas técnicas en el área de Inteligencia Artificial. A continuación veremos 2: “Machine Learning” y “Deep Learning”.

¿Qué es “Machine Learning”?

Machine Learning (Aprendizaje automático) son algoritmos que mejoran su rendimiento en una tarea a través de la experiencia.

es una técnica de inteligencia artificial que te permite decirle a la computadora “en base a estos ejemplos, encuentra la forma de resolver el problema”.

Esa es una diferencia clave con algoritmos normales, donde el programador es el encargado de encontrar la forma de resolver el problema.

Veamos un ejemplo. Digamos que queremos saber si un examen de PAP (Papanicolao) tiene células anormales, ¿cómo se hace esto con Machine Learning?

Haces un programa al cual le pasas imágenes de los exámenes ya clasificados como “normal” y “anormal”. Luego, el programa “estudia” los exámenes y “aprende” a descifrar el problema.

La parte de “estudiar” y “aprender” es automática.

Es mágico.

¿Qué es “Deep Learning”?

Es un tipo de algoritmo de Machine Learning, construido a partir del principio de redes neuronales (fuente).

Es decir, es un tipo particular de algoritmo de Machine Learning. Es una herramienta más para resolver problemas.

Esta técnica es popular por su uso en clasificación de imágenes y de texto. Son algoritmos muy buenos para detectar patrones de forma automática.

Por ejemplo, en mi proyecto final de DATA SCIENCE en Desafio Latam, utilizamos Deep Learning para buscar anormalidades en muestras del examen Papanicolao (PAP).

¿Qué es la “Automatización”?

Muchos confunden automatización con inteligencia artificial.

La automatización es simplemente automatizar alguna tarea repetitiva.

La inteligencia artificial podemos verla como un medio para lograr automatización. De hecho, puedes automatizar muchas cosas con algoritmos corrientes.

Una aplicación sencilla que te ayuda a calcular el IMC de un paciente es un tipo de automatización, pues te ahorra hacer los cálculos mentalmente.

Algo más elaborado son extensiones de Chrome que te permiten ejecutar acciones repetitivas en el explorador. Por ejemplo, si pasas datos de un excel a una plataforma web habitualmente, una herramienta de ese estilo podría hacerlo por ti.

Así que cuando hablamos de automatización, no hablamos necesariamente de inteligencia artificial.

¿Qué es el “Blockchain”?

Blockchain es una tecnología que permite que distintos participantes que no confían entre sí, puedan ponerse de acuerdo sin la necesidad de un árbitro.

En finanzas, podemos crear una moneda virtual que nos permita transferir a otras personas sin necesidad de un banco.

En salud, su uso está en estudio y evaluación. Uno de los usos que más me gusta es en la cadena de suministro farmacéutica, donde por ejemplo, puedes llevar un registro de los cambios de propiedad de los medicamentos recetados a nivel nacional, sin intervención de un tercero.

Puedes ver el post “Blockchain en salud” para más detalle y ejemplos de esta tecnología.

¿Qué es “Big Data”?

Big Data son técnicas y tecnologías que te permite “trabajar” con “grandes cantidades de datos”.

Con trabajar me refiero a procesar los datos para obtener alguna información de utilidad. Puede ser algo tan simple como obtener un promedio o algo más complicado como estimar un valor futuro.

Con grandes cantidades de datos me refiero a una cantidad tal que un computador normal no pueda procesarlos.

Es clave que estos dos conceptos estén presente. Puede que tengas que guardar mucha información, pero si no tienes que trabajarla, no necesitas Big Data. Simplemente necesitas un disco duro extra.

¿Qué es “IoT”?

“IoT” (de “Internet of things”, “Internet de las cosas”) es un concepto que se refiere a la conexión digital de dispositivos cotidianos con internet.

Un ejemplo en medicina puede ser un termómetro que se utilice a la hora de transportar fármacos que requieran estar bajo una cierta temperatura. El termómetro podría estar conectado a Internet para que los operadores vean en tiempo real las variaciones de temperatura.

Conclusiones

Una de las razones por las que los conceptos se mezclan es porque hay sinergias entre estas tecnologías:

IoT te permite conectar dispositivos a internet, y por ende, recolectar gran cantidad de datos. Si quieres demostrar inmutabilidad de estos, Blockchain es una opción. Y si necesitas trabajar sobre esos datos, seguramente necesitarás Big Data. Y si quieres extraer patrones o aprender de la información recolectada, tendrás que utilizar algún algoritmo de inteligencia artificial.

A continuación una tabla resumen con las tecnologías y conceptos definidos en este post.

Tecnología	Descripción	Ejemplo
Automatización	Lograr ejecutar una tarea de forma automática	Generación de alertas cuando hay bajo stock de insumos
Algoritmo	Reglas que muestran el paso a paso necesario para la realización de un problema	Una aplicación que al responder un cuestionario te diga el riesgo de tener COVID
Inteligencia Artificial	Cualquier sistema que perciba su entorno y tome acciones que maximicen sus posibilidades de lograr sus objetivos	Predecir la probabilidad de rehospitalización de un paciente
Machine Learning	Son algoritmos que mejoran su rendimiento en una tarea a través de la experiencia.	Detectar el núcleo en una imagen de una célula
Deep Learning	Un tipo de Machine Learning que imita la red neuronal del cerebro humano para resolver un problema	Detectar el riesgo de cáncer en un examen PAP
Blockchain	Tecnología que permite que distintos participantes que no confían entre sí, puedan ponerse de acuerdo sin la necesidad de un árbitro.	Llevar un registro de los cambios de propiedad de los medicamentos recetados a nivel nacional, sin intervención de un tercero (descentralizado)
Big Data	Son técnicas y tecnologías que te permiten “trabajar” con “grandes cantidades de datos”.	Datos recolectados por los Glucómetros a nivel nacional
IoT	Es un concepto que se refiere a la conexión digital de dispositivos cotidianos con internet	Glucómetros conectados a internet

En futuras publicaciones continuaremos explicando términos utilizados en el ambiente de la informática.

Informática para no informáticos #2

Nicolás Gómez — Fri, 22 Jan 2021 14:00:00 GMT

Continuemos con el ejemplo del post anterior: te hacen jefe de una unidad de informática en un centro de medicina, y tu primera medida es implementar un software de gestión para el centro.

Finalmente decidiste contratar una empresa de desarrollo de software.

¿Ahora qué? te preguntas…

En este post, veremos las etapas típicas de un proyecto de creación de software, de manera de que te enteres en qué consiste y qué responsabilidades tendrías tú como “cliente”.

Etapas en un proyecto de desarrollo de software

Un proyecto de desarrollo de software es parecido a otros tipos de proyectos. La diferencia central es que el resultado del proyecto es un software o programa.

Este tipo de proyectos se realizan bajo un proceso, el cual define la forma en la cual se llevará a cabo el proyecto.

Es importante que el proceso que utilice la empresa que contrates te involucre a ti y a los usuarios finales. Si no es así, ¡tu proyecto está destinado a fallar!

¿Cómo saber sí la empresa de software me involucrará a mí y a los usuarios finales?

La forma fácil es preguntar “¿Cuándo podremos tener una versión inicial?”

Si te dicen que en 1 año más, lo más probable es que utilicen un proceso en cascada, donde se intenta definir TODO el proyecto en un principio, parecido a la construcción de un edificio.

El problema es que al comienzo uno no tiene muy claro lo que quiere ni las características que debe tener el software para que sea fácil de usar por los usuarios. A lo más puedes tener ideas (hipótesis) de una posible solución. Incluso cuando todos los involucrados (proveedor, cliente y usuarios) consideren que una solución “en papel” es perfecta, la única manera de saberlo con seguridad es utilizando el software. Así que mientras antes lo probemos, mejor.

Idealmente, la empresa que contrates utilizará una “metodología ágil”. Recordando el post anterior, este tipo de metodología busca entregar software que te ayude lo más rápido posible de manera que en un par de semanas ya veas y uses la primera versión. Las siguientes versiones se hacen paso a pasito (cada 2 ó 6 semanas). El plus de estas metodologías es que buscan involucrar al cliente y los usuarios finales a lo largo de todo el proyecto.

Aquí hay una imagen que revela el “paso a pasito” que es ideal en proyectos de software:

Imagen extraida de "What is Minimum Viable (Data) Product?"

¿Cuáles son las etapas en un proyecto de software?

Independiente del proceso que la empresa utilice, existen actividades claves que son transversales y comunes. Las voy a definir como etapas secuenciales porque así es más fácil entender. Sin embargo, en la práctica son actividades que se realizan a lo largo de todo el proyecto.

Las actividades base son las siguientes:

Etapa de concepción: descubrir el objetivo principal del proyecto y riesgos asociados.
Etapa de elaboración: definir un software mínimo que cumpla con el objetivo del proyecto.
Etapa de construcción: construir el software mínimo rápido y manteniendo la calidad. El objetivo es tener un software usable.
Etapa de estabilización: el software está instalado y los usuarios ya lo están usando. Existen algunas observaciones que requieren ser atendidas (por ejemplo: errores o problemas de uso). Puede haber una fase de transición, donde el proveedor capacita a los usuarios, y una fase de garantía, donde el proveedor se asegura que el sistema no tenga problemas ni bugs.

Etapa 1: Concepción

Tú como cliente tienes un problema que requiere solución. Así que tu labor es tener más o menos una idea de cuáles son los problemas que quieres que el software te ayude a solucionar.

Es normal que no tengas conocimientos para definir una solución ni que tengas total claridad del problema de fondo.

Un buen proveedor te ayudará a descubrirlo en un proceso que los informáticos llaman “levantamiento de requisitos”.

En el levantamiento de requisitos las empresas evalúan la situación actual, te ayudan a descubrir una situación deseada (meta) y comienzan a pensar sobre posibles caminos que te permiten llegar a la meta. Puede darse el caso de que el camino NO SEA construir un software a la medida (lo que quieres), sino que sea utilizar uno ya existente (lo que realmente necesitas).

Algunas empresas cobran por esto, parecido a una consulta médica. Hay otras que lo hacen gratis como parte de su estrategia de ventas.

Al final de esta etapa, tú y el proveedor tendrán una idea si el proyecto es factible, considerando costos, plazos y el objetivo del proyecto.

¿Cómo se ve esto en la práctica? Tienes una o varias reuniones con el equipo del proveedor, donde con un screening te van haciendo preguntas para descubrir que es lo que realmente necesitas (la meta). Luego, es posible que te llegue una propuesta de trabajo que indique el paso a paso, plazos y cuánto va a costar. Esta propuesta puede involucrar crear el software o ser un ante proyecto para definir mejor el software a construir. Luego tu opción es aceptar la propuesta o rechazarla.

Etapa 2: Elaboración

La etapa de concepción es el por qué, mientras que la de elaboración es el cómo.

En esta etapa, tú y tu equipo junto a el proveedor trabajan en definir un producto mínimo viable (MVP): un producto bien chiquito que cumpla con el objetivo más importante del proyecto.

Es importante que en esta etapa se involucren todos los interesados: tú, los usuarios finales y el equipo proveedor. Muchas veces el proveedor no sabe nada sobre tu contexto, y si ellos diseñan el sistema sin tu ayuda, es probable que el resultado sea un software para informáticos y no para clínicos (¿suena familiar?).

El resultado de esta etapa puede ser bocetos, diseños o mockups del sistema. El nivel de involucramiento de los participantes de tu lado debe ser al menos de dar feedback sobre los bocetos.

Es posible que esta etapa considere solo una parte de todo el sistema, dejando para “más adelante” la definición del resto. Recuerda que estas etapas pueden irse repitiendo a lo largo del proyecto, es normal y deseable hacerlo “paso a paso” en vez de definir todo de un golpe.

Nota: Muchas veces esta etapa de “Elaboración” es lo que algunas empresas venden como “ante proyecto”.

Una vez ya están validados los bocetos, pasamos a…

Etapa 3: Construcción

En construcción el proveedor hará su “magia” y luego de un tiempo razonable (2 a 6 semanas) te entregarán un software funcional.

El software que construyan va en línea con el por qué (concepción) y con el cómo (elaboración). Pueden haber diferencias, y es posible que algo que visualizaron en un inicio no funcione muy bien en la práctica.

Durante la construcción, el equipo podrá preguntarte cosas o darte alternativas para ciertos escenarios.

Etapa 4: Estabilización

La estabilización es la etapa en la cual el software ya está instalado y los usuarios finales lo están usando.

Es posible que existan errores o fallas. Lo importante es que la empresa que construyó el software te ofrezca un periodo de garantía donde se comprometa a solucionar los problemas que surjan con el uso. Existen 2 grandes clases de problemas:

Bug: existe un error o un defecto que hace que el programa no funcione correctamente. Generalmente ocurren por secuencia de pasos que el programador no consideró (casos bordes) pero que el usuario ejecutó.
Problema de usabilidad: es cuando existe una acción que es difícil de realizar en el sistema.

La gracia de pasar por un proceso de “elaboración” donde involucre a los usuarios finales y además de construir el software en iteraciones, es que estos problemas aparecen antes.

Palabras finales

Espero que este post te haya sido de ayuda para entender cuáles son las etapas de un proyecto de software y para que te hagas una idea de cuál es tu nivel de involucramiento.

La verdad es que los proyectos de software son colaborativos. Y como tal, no es algo que mandas a construir y luego te olvidas. Es importante que tú y tu equipo tengan una colaboración activa en el proceso de construcción, así que tienes que considerar esto como parte de la inversión de recursos.

En futuras publicaciones continuaremos explicando términos utilizados en el ambiente de la informática, para seguir creando puentes entre ambos mundos.

Iniciando una carrera Tech desde Enfermería

Eliana Quijada — Fri, 15 Jan 2021 10:00:00 GMT

Cuando digo que soy enfermera y también desarrolladora de software, las personas se sorprenden e intrigan por la extraña combinación.

Generalmente esa conversación continua con preguntas como: ¿Por qué decidiste cambiar de profesión?, ¿Cómo pudiste hacerlo?, ¿Ha sido muy difícil?.

Por este motivo, voy a contar parte de mi historia. Quizás esta historia te puede ayudar a visualizar de que informática y salud no son mundos opuestos, o tal vez te puede motivar si tienes ganas de aprender informática.

El problema del exceso de información en salud

En los últimos años que ejercí la enfermería de forma tradicional, estuve en un cargo mucho más administrativo que clínico. Era la encargada de la continuidad de la atención de una sala en un hospital público.

Mi labor consistía en saber todo lo que sucedía en la sala, desde la atención que recibía cada uno de los pacientes hospitalizados (en qué etapa de su tratamiento se encontraban, si había alguna complicación, si se necesitaba gestionar algún examen especial, y un largo etcétera), hasta velar porque hubiese stock de todos los insumos esenciales para la atención (desde jeringas y sueros, hasta cloro para limpiar las superficies).

Este cargo me ayudó a aprender muchas cosas de cómo funciona en realidad el sistema público en nuestro país, la burocracia que implica, los malabares que se hacen con los escasos recursos y sobre todo, la enorme cantidad de información que se maneja día a día (tanto información clínica, como de insumos, de infraestructura, de personal, etc).

Este exceso de información me llevó a comenzar a cuestionarme la forma en la que se estaba manejando y aprovechando todo ese mar de datos.

¿Por qué desarrollo de software?

Paralelamente, en el ámbito más personal sentía que debía encontrar alguna labor en la que pudiese aprovechar mis habilidades personales.

Llevaba poco más de 5 años trabajando como enfermera, y creo que realmente ponía el corazón y todo mi entusiasmo en lo que hacía. Sin embargo, me era inevitable sentir que algo me faltaba, y es aquí cuando por cosas de la vida, comienzo a conocer un poco de la programación y su lógica, y simplemente fue como un flechazo a primera vista.

Volviendo al ámbito laboral, el tener una perspectiva más amplia me permitió sentir la frustración de querer realizar muchas cosas en beneficio de la atención del paciente, pero que por temas de tiempo, recursos y apoyo, era habitual que no pudiesen realizarse. Y al mismo tiempo, me sirvió de motivación para buscar la manera de poder aportar a mejorar la atención con estas nuevas habilidades que estaba adquiriendo.

Así fue como tomé la para algunos “alocada” decisión de renunciar a mi puesto y dedicarme 100% a aprender de esta nueva área, y adquirir poco a poco la experiencia necesaria para generar productos de calidad, que sean realmente un aporte para mejorar la atención de salud.

¿Cómo empezar a aprender a programar?

Mi primer paso fue realizar cursos cortos online sobre las bases de la programación, los cuales hice mientras aún estaba trabajando. Estos funcionaron como mi prueba de admisión para saber si realmente me gustaba y si sentía que tenía habilidad para esto.

Como terminé muy contenta estos cursos, comencé la búsqueda de cómo continuar. La verdad es que me hubiese encantado tener la posibilidad de estudiar ingeniería en informática, pero ni el tiempo ni los recursos me acompañaban para volver a tomar una carrera universitaria completa.

Entonces llegó a mis oídos la existencia de los Bootcamp, que son cursos intensivos y prácticos, que en muy poco tiempo (meses en vez de años) intentan entregar conocimientos y herramientas que te permitan entrar al mercado laboral.

La definición suena un poco disruptiva con respecto a la forma convencional a la que estamos acostumbrados, pero definitivamente con la suficiente dedicación y sacrificio, el método funciona.

En mi caso opté por entrar a 4Geeks, una de las características que más me atrajo es su soporte profesional, algo muy necesario sobre todo si no tienes un título que respalde tus conocimientos en el área.

En realidad, hay muchas maneras de poder aprender sobre informática, así como muchos perfiles para aplicarla en salud. En ningún caso es obligación aventurarse a hacer un cambio tan radical como renunciar y volver a estudiar, pero creo que cada uno debe tomar el camino que más le acomode y agrade.

¿Cambio de profesión?

La verdad es que no siento que realmente sea un “cambio”, más bien siento que es un “ampliar conocimientos”.

Soy enfermera y nunca dejaré de serlo, no me gusta cuando suelen referirse a “cuando eras enfermera”, como si fuese algo del pasado. Es posible aportar al cuidado de las personas desde una mirada que integre la enfermería con el desarrollo de software.

Además, ¿quién mejor para saber cuáles son los problemas y dolores que tienen los profesionales de salud, que alguien que estuvo en su lado del cristal?

Siento que es necesario que dentro del mundo de los “creadores de soluciones” hayan personas que no sólo puedan hablar el idioma, sino que también hayan tenido las necesidades de los que están “donde las papas queman”.

Mientras trabajaba en el hospital, cada día me tocaba sufrir con los sistemas informáticos poco amigables, con su usabilidad de la década de los 90 o muchas funcionalidades inútiles para el quehacer diario. También me tocó lidiar con la infinidad de papeles, formularios, pautas y reportes, que se perdían o requerían escribir muchas veces la misma información.

Es realmente esperanzador que con el aporte de la informática, todo esto podría reducir su complejidad, disminuyendo el esfuerzo y tiempo necesario, para así destinarlo a lo realmente importante: la atención del paciente.

Informática para no informáticos #1

Nicolás Gómez — Thu, 07 Jan 2021 18:00:00 GMT

Imagina que el día de mañana te hacen jefe de una unidad de informática en un centro de medicina, y que tu primera medida es implementar un software de gestión para el centro.

Digamos que viste todos los sistemas informáticos existentes y que ninguno te convenció. ¿Qué hacer ahora?

Una de tus opciones es contratar a una empresa para que cree un sistema informático que se ajuste a lo que tu centro requiere.

Así que comienzas a buscar empresas que se encarguen de esto. Pero luego de una búsqueda en Google y de ver muchas páginas de empresas de informática, quedas en blanco.

¿Qué pasó?

Pasa que la mayoría de este tipo de empresas utilizan un lenguaje poco amigable para decirte qué es lo que hacen y cómo te pueden ayudar. Abundan los “entregamos las mejores soluciones a tus necesidades”, “soluciones a medida”, “metodologías ágiles”, y mi favorito: “usamos las últimas tecnologías”.

Dicho esto, la idea de este post es ayudarte a entender lo que quieren decir los proveedores de software con su jerga.

Nota: Cada pregunta está basada en lo que dicen páginas reales de proveedores 🙈

¿Qué es el “desarrollo de software”?

El desarrollo de software es la acción de construir un software. “Estoy desarrollando un sistema” es como decir “estoy construyendo un sistema”.

¿Qué es “outsourcing”?

Outsourcing es lo que hace una empresa cuando contrata a un tercero para solucionar una problemática interna.

En el ejemplo, al contratar una empresa externa, estás haciendo “outsourcing”.

Lo contrario es hacer un “desarrollo propio” que significa contratar tus propios ingenieros y que ellos creen el software.

¿Qué es el “desarrollo a la medida”?

Piensa que quieres comprarte ropa. Una de tus opciones es ir al Mall y comenzar a probar distintas prendas hasta que encuentras una que te guste y te quede bien.

Si no hay nada que te quede, otra opción es mandar a hacer ropa. En este caso, vas con un sastre, quien te toma distintas medidas y crea una prenda perfecta para ti.

Cuando hablamos de “desarrollo a la medida”, nos referimos a este último caso. La empresa proveedora es el “sastre” y la vestimenta es el software.

¿Qué significa “levantamiento de requisitos”?

Continuando con la analogía, el proceso de “tomar distintas medidas” en el software es conocido como “levantamiento de requisitos”. Aquí los proveedores se encargan de averiguar cuáles son los problemas que quieres solucionar con el sistema.

¿A qué se refieren con “entregar solución a tus necesidades”?

Cuando los informáticos hablan de “necesidad”, se refieren a algo que tú necesitas que el software haga. Por ejemplo, podrías necesitar que el sistema te ayude a gestionar los turnos de tu personal.

Cuando los informáticos hablan de “soluciones”, se refieren al resultado del proyecto: el sistema informático.

Así que “entregar solución a tus necesidades” es como decir “construimos sistemas informáticos que hagan lo que tú necesitas que haga”.

¿Qué son las “metodologías ágiles”?

Nada de raro es que aparezca en la página de una empresa “trabajamos con metodologías ágiles”. ¿A qué se refieren con esto? ¿Salen a trotar mientras trabajan?

Una “metodología ágil” es un proceso particular para la construcción de software que se basa en “principios ágiles”.

No voy a entrar en el detalle filosófico, ya que para ti como cliente te importa lo práctico. Y lo práctico es que la metodología busca entregar software que te ayude lo más rápido posible: en vez de esperar años o meses para ver tu software, en un par de semanas podrás ver la primera versión.

Las siguientes versiones te las van a ir entregando a lo Luis Fonsi, paso a pasito. En cada paso (cada 2 ó 6 semanas aprox.) verás a tu sistema incorporar nuevos cambios. Y no solo eso: tanto el cliente (tú) como los usuarios participarán en el proceso, deberán involucrarse probando las funcionalidades y proporcionando retroalimentación.

La gracia es que cada versión realmente funciona y puedes usarla.

Así que cuando dicen “metodología ágil”, piensa en que te van a ir entregando el software de a poquito y que tú y los usuarios finales deben tener tiempo para participar del proceso de pruebas y entregar retroalimentación.

¿Y por qué no mandar a hacer el software y olvidarse? Bueno… En los inicios del desarrollo de software se intentó hacer esto. Definir muy bien los requisitos al comienzo, y luego simplemente programarlos. Esta metodología se llama “Cascada” y no funcionó:

La tasa de éxito es baja (10%)
Estimaciones de tiempo y costos varían hasta un 400%.

¿Cuáles son las “últimas tecnologías”?

En la práctica no te va a importar mucho las tecnologías que la empresa use. Como cliente, te importa que solucionen la problemática y listo, independiente de las herramientas.

Cuando una empresa dice que utiliza las “últimas tecnologías”, es como cuando una empresa de construcción dice “usamos el último modelo de taladro”.

¿A qué se refieren con “soluciones escalables”?

Ya hablamos que “solución” se refieren al sistema que te van a construir.

Cuando hablamos de “escalable”, nos referimos a un sistema que funcione bien independiente de la cantidad de usuarios que lo estén usando.

Por ejemplo, cuando una página deja de funcionar en un Cybermonday (por el alto tráfico), decimos que la página no es escalable.

La verdad es que escalable es una propiedad sobrevalorada. No todos los sistemas deben ser infinítamente escalables. Deben funcionar bien bajo límites razonables, los cuales se identifican en base al uso que le quieres dar.

Por ejemplo, si tu sistema lo usarán sólo las enfermeras, y tienes 200 enfermeras, no necesitas un sistema que soporte millones de usuarios.

Palabras finales

Espero que esta mini guía sobre la jerga que utilizan las empresas de desarrollo de software te sea útil como primer acercamiento.

En futuras publicaciones continuaremos explicando términos utilizados en el ambiente de la informática, para seguir creando puentes entre ambos mundos.

Blockchain en salud

Nicolás Gómez — Mon, 28 Dec 2020 10:00:00 GMT

“¿Y qué pasa con el blockchain?” es una pregunta que he escuchado en charlas relacionadas con tecnologías en salud.

Lo cual no es raro, ya que algunos la definen como la invención más disruptiva desde la creación de internet.

Sin embargo, como pasa con toda nueva tecnología, hay mucho hype y humo alrededor del concepto.

A pesar de esto, ¿tendrá algún valor en el ámbito de la salud?

Breve introducción a Blockchain

Antes de continuar, hay que tener una idea de qué es Blockchain.

Blockchain es una forma segura de guardar datos. Es parecido a una base de datos pero en blockchain los datos guardados son inmutables y casi imposibles de cambiar.

En su forma más simple, se refiere a una estructura de datos que por diseño nos permite decir “sí, estos son realmente los datos y no los he cambiado”.

Así que siempre que hablemos de Blockchain, tenemos que pensar en integridad de datos.

Si quieres aprender el lado técnico de una cadena de bloques, te sugiero ver la charla en español Understanding the Bitcoin Protocol and the Blockchain Structure que tiene detalles técnicos básicos y sin humo, o este post donde el autor hace un ejemplo sencillo para saber cómo funciona.

Dicho esto, cuando la gente habla de Blockchain, por lo general se refieren a las técnicas y tecnologías utilizadas por Bitcoin que involucran muchos conceptos interesantes tales como teoría de juegos, criptografía y sistemas distribuidos.

Así que muchos ven a Blockchain más allá de la estructura de datos y lo ven más como un libro de registros decentralizado (“Distributed Ledger”), ya que ese fue el uso que lo hizo popular.

Es por eso que una de las características que suelen decir de Blockchain es que garantizan que todo el mundo vea la misma información, sin que una parte tenga que confiar en que la otra sea honrada.

Blockchain en Salud

En Application of Blockchain Technology in Healthcare: A Comprehensive Study (fuente) listan los usos principales de Blockchain en salud, en base a papers publicados.

Los autores clasifican los estudios en 4 usos:

Historia clínica electrónica (Electronic Health Records)
Monitoreo remoto de pacientes (Remote Patient Monitoring)
Cadena de suministro farmacéutica (Pharmaceutical Supply Chain)
Seguros médicos (Health Insurance Claims)

Uso 1: Historia clínica electrónica

La mayoría de usos y prototipos están alrededor de la historia clínica electrónica de los pacientes. En particular, se utiliza Blockchain para ayudar a la gestión de estos registros.

Por ejemplo, está “MedRec” (del MIT Media Lab) que propone un enfoque descentralizado para gestionar la autorización, los permisos y el intercambio de datos entre los stakeholders en salud (instituciones, hospitales, etc). Uno de los objetivos que busca este proyecto es que sean los mismos pacientes los dueños de sus datos, de manera que cada uno decida quién tiene acceso.

Uso 2: Monitoreo remoto de pacientes

En el mundo del monitoreo remoto de pacientes, Blockchain puede ser usado en conjunto con IoT para almacenar, compartir y obtener datos recolectados.

En “Tamper-Resistant Mobile Health Using Blockchain Technology” los autores proponen un sistema resistente a manipulación basado en Blockchain. Hicieron la prueba con una aplicación móvil que enviaba información sobre una terapia para el insomnio.

El hecho de guardar los datos que envían los dispositivos en Blockchain puede ayudar también a la trazabilidad y auditoria de los datos, lo cual podría ayudar a evitar negligencias o detectar culpables en caso de haber una.

Uso 3: Cadena de suministro farmacéutica

Algunos usos buscan abordar los problemas de falsificación de medicamentos o usos inadecuados.

Por ejemplo, Modum.io utiliza Blockchain para verificar el cumplimiento de los requisitos de temperatura de control de calidad. ¿Cómo? Publica los registros de temperatura de los productos farmacéuticos durante su transporte. Como los datos en la red son inmutables, se puede asegurar que no se manipuló la información de temperatura.

Otro uso es llevar registro completo de la medicación de un paciente: desde el registro de un medicamento particular hasta su prescripción y uso. Esto es lo que hicieron en “A Novel Medical Blockchain Model for Drug SupplyChain Integrity Management in a Smart Hospital”, de manera que registran cada transacción en la red Blockchain. Lo que no me quedó claro es porque esto ayuda a evitar medicamentos falsificados (no leí el paper completo 😅…)

Otro ejemplo es Mediledger, que gracias a esta tecnología busca que los líderes farmacéuticos registren el cambio de propiedad de los medicamentos recetados.

Uso 4: Seguros médicos

En MIStore, los autores proponen un sistema para guardar seguros médicos utilizando Blockchain. Uno de las ventajas es que las aseguradoras pueden obtener la información de gastos del paciente pero no el detalle completo.

Desafíos de Blockchain en Salud

En el ámbito de salud, muchas cosas viven fuera del mundo digital. Por ejemplo, para Historia clínica electrónica, ¿cómo confiamos que los ingresos de un profesional de la salud son confiables? ¿Cómo extendemos la confianza a dispositivos de monitoreo IoT?

Esto es importante. Blockchain asegura que la información que almacenas lo hiciste tú, a cierta hora y que toda la información guardada no ha sido modificada por un tercero. Pero no valida si la fuente de datos en sí es confiable, ya que eso se escapa del mundo digital.

Es por eso que una de las dificultades de Blockchain es el cómo extender la confianza del mundo digital al mundo físico.

Otro gran desafío es que toda la tecnología y estudios se basan en que ya hay participantes digitalizados. En ambientes no digitalizados (donde hay mucho registro de papel) no creo que la herramienta sea una ayuda.

Y por si fuera poco, la interoperabilidad sigue siendo un problema. Por ejemplo, “MedRec” busca ser una especie de registro de fichas médicas (dónde encontrar la información) pero eso no garantiza interoperabilidad. Una cosa es saber dónde está la información, y otra es asegurarnos que todos los lugares donde se guarda hablen el mismo lenguaje.

Conclusiones

Blockchain es una de las tecnologías de moda en el mundo, y no es una tecnología tan madura si la comparamos con Internet o IA. Es por eso que hay que tener cuidado en caer en falsas promesas o en el HYPE.

De hecho, hay modelos de decisión que te ayudan a saber si aplicar blockchain es buena idea, e incluso un paper llamado “Do you need Blockchain?” que te ayuda a saber si realmente necesitas la tecnología.

Su uso en el ámbito de la salud está en estudio y evaluación. Existen meta estudios que nos ayudan a saber en qué está tales como “Application of Blockchain Technology in Healthcare” (fuente) y “Blockchain in Health Care Innovation: Literature Review and Case Study From a Business Ecosystem Perspective” (fuente).

¿Existe valor en la tecnología? Sí, definitivamente. ¿Soluciona todos los problemas? No.

Referencias

Escribiendo este post, me encontré con las siguientes artículos:

How a blockchain works… Let’s make one! — Daniele Favi.
Understanding the Bitcoin Protocol and the Blockchain Structure — Martin Ugarte.
Bitcoin: A Peer-to-Peer Electronic Cash System — Satoshi Nakamoto
How to time-stamp a digital document — Stuart Haber & W. Scott Stornetta
Blockchain beyond the hype: What is the strategic business value? — Brant Carson para McKinsey Digital.
Qué son los ‘smart contracts’ o contratos inteligentes — Luz Fernández para BBVA.
Blockchain In Healthcare Today, Vol 3, 2020
Application of Blockchain Technology in Healthcare: A Comprehensive Study — Rim Ben Fekih & Mariam Lahami
Do you need a blockchain? — Karl Wüst & Arthur Gervais
Blockchain & Healthcare Standards — PDF de slides por Ewout Kramer.
Blockchain in Healthcare — Blockgeeks.
Where is the blockchain Revolution — Daniele Favi.

Ejemplo de interoperabilidad en salud

Eliana Quijada — Thu, 17 Dec 2020 18:00:00 GMT

Después de los post anteriores, en donde hablamos de la parte más teórica de la interoperabilidad y sus estándares, ahora compartiré un ejemplo de cómo podrían incluirse los diferentes niveles de interoperabilidad en el flujo de atención de un paciente ficticio.

Contexto

Nuestro paciente se llamará Eddard Stark 🐺, sus cercanos lo conocen como Ned.

Para efectos de este caso, vamos a asumir que todos los centros de atención de salud de Poniente (el continente donde vive Ned Stark) tienen sistemas de registro clínico informático para registrar las atenciones de sus pacientes, así como sistemas para gestionar el funcionamiento de los servicios de apoyo (farmacias, laboratorio, rayos, etc).

Caso clínico

Antecedentes mórbidos

Ned tiene antecedentes de hipertensión arterial, por lo que ha sido tratado desde hace años en el CESFAM de Invernalia. A finales de abril es hospitalizado en el servicio básico de medicina del Hospital del Norte con diagnóstico de Neumonía por COVID-19, pero a la entrevista de ingreso, no recuerda el nombre de los medicamentos que toma actualmente.

En este punto de la atención es útil que el sistema de información del CESFAM y el utilizado por el Hospital del Norte puedan interoperar.

Así, el nuevo equipo tratante obtendrá de forma fácil y precisa la información detallada de los antecedentes y el tratamiento que ha recibido Ned, previniendo posibles errores que podrían originarse de la interacción de medicamentos.

Si hablamos de interoperabilidad sintáctica, es decir, de la estructura de la información compartida, se podría utilizar el estándar de mensajería HL7 FHIR.

Hospitalización en servicio de cuidados básicos

Mientras Ned está hospitalizado se le realizan exámenes de sangre (hemograma, pruebas de coagulación, gases arteriales, pruebas para medir función renal y hepática).

Para que el laboratorio reciba la solicitud de los exámenes y posteriormente entregue los resultados, es necesario exista un intercambio de información dentro de la misma institución (entre el sistema de información utilizado por el servicio de medicina y el del laboratorio).

Para este proceso podría tener relevancia que además de la interoperabilidad sintáctica, se incorpore el estándar de terminología LOINC, indicando cuáles son las pruebas solicitadas y realizadas.

Traslado a servicio de cuidados intensivos

Después de una semana hospitalizado, Ned presenta un deterioro en su estado clínico por lo que necesita ser trasladado a una Unidad de Cuidados Intensivos, pero el hospital en el que actualmente se encuentra no tiene disponible camas de alta complejidad, por este motivo debe ser trasladado al Hospital de Desembarco del Rey.

En este caso es muy importante que el equipo de la Unidad de Cuidados Intensivos pueda tener acceso a la historia clínica de Ned desde el hospital de origen.

Regreso a servicio de cuidados básicos

A las tres semanas Ned presenta una notable mejoría en su estado de salud, por lo que ya está en condiciones de volver a un servicio básico y es retornado a su hospital de origen, para completar su recuperación.

Ahora es necesario el proceso inverso y que el servicio de medicina pueda obtener la historia clínica de Ned incluyendo los datos de las tres semanas que estuvo en UCI.

En los dos últimos casos mencionados es muy importante considerar la interoperabilidad sintáctica, de manera de que exista intercambio óptimo de la información entre los sistemas de las dos instituciones involucradas y así mantener actualizados todos los datos clínicos del paciente.

Alta

Luego de una semana de recuperación Ned es dado de alta y se le indica continuar con sus controles en su CESFAM.

Para esta etapa de la atención es necesario que el centro de atención primaria pueda acceder al documento clínico con el resumen de la hospitalización del paciente, así como todas las indicaciones entregadas al momento del alta.

Conclusión

Como conclusión final, en el flujo de atención de un paciente pueden identificarse varios puntos en los que es necesario el uso de interoperabilidad en los sistemas informáticos de salud, para así permitir que exista un adecuado intercambio de la información del paciente, evitando errores y además ayudando a que los diagnósticos y tratamientos sean oportunos.

Mi experiencia en el Tech Connect 2020

Nicolás Gómez — Wed, 09 Dec 2020 18:00:00 GMT

Participé por primera vez en el evento de interoperabilidad Tech Connect

La edición 2020 por el contexto de pandemia fue 100% remota (en Zoom). Lo único malo de esta modalidad es que no hubo coffee breaks 🐷… pero bueno.

¿Qué es el techconnect? es un encuentro anual con talleres y charlas sobre interoperabilidad en salud.

¿Interoperabiliwhat? La interoperabilidad en salud es hacer que los distintos sistemas informáticos se comuniquen entre sí. Puedes leer más de esto aquí.

En este post haré un mini review sobre el evento y comentaré sobre las charlas que me gustaron más.

Cómo fue el Techconnect

En una palabra: intenso.

Hubo jornada de charlas todas las mañanas de lunes a jueves entre 9:00 y 13:00. No soy alguien mañanero, así que sufrí un poco por eso.

Y no solo eso. Posterior a las charlas, las personas que se registraron al desafío de interoperabilidad debían trabajar en los problemas planteados.

Esa semana me la tomé libre y me dediqué a tiempo completo a aprender sobre interoperabilidad, participando de las charlas y además de los desafíos.

¿De qué tratan los desafíos?

Cada ejercicio debías hacer lo que un sistema informático haría en una situación dada.

Por ejemplo, un enunciado podría ser algo del estilo:

“Llegaron los resultados del examen de perfil hepático que se hizo Juanito Perez RUT 11.111.111-1 la semana pasada debes informarle de esto al Laboratorio central del minsal”

Luego, cada participante debía “programar” el “envío” del examen. La parte de “programación” se hace gracias a un estándar de interoperabilidad llamado HL7 FHIR.

Los ejercicios se realizaron a través de una plataforma chilena construida especialmente para aprender, llamada Huemul. Además, estaban clasificados en distintos contextos (tracks) y dificultades (básico, medio y avanzado).

Por todo esto, el público objetivo podía ser cualquier persona con ganas de aprender, no necesariamente programadores. De hecho, muchas personas que participaron eran clínicos alejados de la programación.

Para los más computines como yo, la parte técnica no era tan complicada (vivo de eso!). Lo difícil era aprender bien la terminología clínica que utiliza HL7, que probablemente a los clínicos les costaba mucho menos. Aunque mi partner en Codeness es enfermera, por lo que gracias a ella pude entender mejor algunas cosas 🙏.

El Desafío Avanzado

Los desafíos de dificultad fácil e intermedia se hacían online en “Huemul”.

El avanzado era diferente, pues tenías que construir una aplicación que se comunicara con plataformas que el equipo organizador puso a disposición (usando HL7 FHIR).

Como me tomé la semana para participar del Techconnect, quise participar en TODOS los desafíos, incluso el avanzado.

Los tracks básicos e intermedio me ayudaron a conocer mejor HL7, conocimiento que utilicé para poder crear la aplicación del track avanzado.

Participé en el caso de uso “Informe Diagnóstico” (enunciado), cuyo objetivo era construir una aplicación que permita crear informes de laboratorio y asociarlos a un paciente.

Puedes ver un video demo de la aplicación que hice aquí. Nota: Los datos que muestra son falsos ya que el CENS bajó los servidores.

Funcionalidades de la aplicación

Las instrucciones del enunciado las encontré súper claras. Detallaba claramente los requerimientos de la aplicación, lo suficiente para que no fuera confuso. En cualquier caso, ante dudas, teníamos acceso a Slack donde podíamos consultar.

El mockup que nos dieron fue este:

Entonces el flujo de la aplicación debía ser más o menos así:

Ingreso de paciente: el usuario debe ingresar un RUT de paciente. Una vez ingresado, mostrar sus datos.
Selección de examen y muestra: El usuario debe ingresar el examen. Para eso, debe seleccionar el tipo de examen (perfil hepático o lipídico), la muestra del paciente y finalmente el RUT del informante (el clínico que está haciendo el ingreso).
Ingreso de resultados: El usuario debe ingresar los resultados del examen.

La otra parte de la aplicación es sobre consulta de resultados:

Donde el flujo era:

Ingreso de paciente: usuario debe ingresar un RUT de paciente. Mostrar sus datos y además los exámenes asociados.
Selección de resultados: usuario podrá seleccionar un examen para ver los resultados.

¿Y dónde está la interoperabilidad aquí?

Bueno, lo que ocurre es que la información que se ingresa o que se consulta vive en distintos servicios:

La información de los pacientes vive en un “Maestro de Pacientes” (MPI).
La información de los prestadores de servicios en un “Maestro de Prestadores de servicios” (HPD).
La información relacionada con muestras y exámenes vive en un “Repositorio Nacional de Exámenes de Laboratorio (RNEL)“.
La información terminológica vive en un “Servidor Terminológico” (ST).

Entonces la aplicación a construir debía ser una especie de intermediario que consumiera datos y que enviara datos a todos estos servicios utilizando FHIR. Así que de cierto modo, hacer este desafío se sintió como resolver un rompecabezas. Aunque armarlo no fue tan fácil…

Si bien el enunciado era claro, por razones obvias no te decían el “paso a paso” de cómo tenías que construir la aplicación.

Por ejemplo, el formulario del perfil lipídico tenía que mostrar campos para ingresar el “Colesterol Total”, los “Triglicéridos”, entre otras cosas. Aquí surgen las siguientes dudas:

¿El formulario se arma a mano? o bien ¿hay que traer la información desde algún servicio?
¿Los rangos de referencia se obtendrán desde algún lado o se manejan a nivel de aplicación?
Las unidades de medida, ¿de dónde vienen?

Luego de explorar la documentación de HL7 pude resolver algunas dudas, y las que no, me las resolvió el equipo del CENS. De hecho, ellos levantaron los rangos de referencia en pleno desafío para que pudiéramos obtenerlos 💪

Recursos FHIR Utilizados

Utilicé los siguientes recursos: Patient, Specimen, Practitioner, Questionnaire, Parameters y Observation.

A continuación detallaré dónde usé cada uno:

Obtener información del paciente

Aquí utilicé el recurso Patient del maestro de pacientes (MPI). La búsqueda se realiza mediante la siguiente llamada

GET /MPI/Patient?identifier=www.registrocivil.cl/RUN|11111111-1

Reemplazando 11111111-1 por el rut que deseabas buscar

Registro de examen

Aquí para la muestra utilicé Specimen. La información se obtiene con una consulta al servidor de exámenes:

GET /HAPI/Specimen/?patient=Patient/:id&type=BLDV

El parámetro id es el ID del recurso paciente encontrado en el paso anterior.

Notar que type=BLDV hace referencia al tipo de muestra de sangre (Blood venous). Es un código de FHIR para esta muestra (ver todos)

Para el informante utilicé Practitioner. La información se obtiene del servidor de prestadores:

GET /HPD/Practitioner?_profile=http://cens.cl/fhir/StructureDefinition/Practitioner-cl&getPractitionerByIdentificationNumber=11111111-1

La selección de “Perfil lipídico” o “Perfil hepático” es información que se guarda de manera local. Al seleccionar uno u otro la app guarda el código LOINC del examen, el cual será usado posteriormente para obtener el formulario a mostrar.

Ingreso de resultados del examen

Para mostrar cada fila de la tabla, utilicé el recurso de tipo Questionnaire. Este recurso representa el formulario a llenar y se obtiene así del servidor terminológico:

GET /ST/Questionnaire/:id

Donde id corresponde al código LOINC del tipo de examen. Para este desafío los utilizados fueron: 24331-1 (perfil lipídico) y 24325-3 (perfil hepático).

El recurso Questionnaire solo te dice que hay que solicitar el “Colesterol total”, los “Triglicéridos”, etc. pero no te dice el tipo de unidad ni los rangos de referencia.

Yo al principio rabiaba con esto, porque no tenía idea de dónde sacarlos y consideraba que deberían estar incluidos. Pero Marcelo Cabello (CENS), me dijo que los rangos de referencia dependia de varias cosas como por ejemplo la edad del paciente. Así que… bueno, toda la razón 😓

Sin embargo, levantaron datos para que pudieramos consultarlo. Lo cual se hacía con la siguiente consulta:

GET /ST/CodeSystem/$lookup?system=http://cens.cl/lab-ref-ranges&code=:code

la cual entregaba un recurso de tipo Parameters con las unidades y los rangos de referencia. El parámetro code es el código LOINC del dato del formulario a llenar. Por ejemplo, en el caso del colesterol, el código es 2093-3

Nada que adivinar aquí, ya que el recurso Questionnaire trae consigo esta información.

Al enviar el examen

Al enviar el formulario, se toman todos los datos requeridos y se envía al RNEL (Repositorio Nacional de Exámenes de Laboratorio) los resultados. Esto se hace creando un recurso de tipo Observation mediante la llamada:

POST /HAPI/Observation

Buscar exámenes de un paciente

Aquí se usa el recurso Patient y Observation.

La búsqueda del paciente es la misma que en el ingreso. Una vez encontrado, se hace la solicitud para obtener los exámenes del paciente con la llamada

GET /HAPI/Observation/?subject=Patient/:id

donde id es el ID del recurso Patient.

Consideraciones de usabilidad

Mantuve la estructura que el equipo del CENS propuso con el mockup. Pensé en cambiarlo a un formulario por pasos, pero no lo hice porque quizás es buena idea de que tenga ciertas similitudes con una hoja de papel.

Incluí validación de datos requeridos con un feedback visual (asterisco *) que indicara los campos requeridos:

Para campos que requieren información previa, como por ejemplo las muestras y los resultados del examen, decidí mostrar un cuadro que indicara que es necesario llenar cierta información previa:

Hice obligatorio la selección del tipo de examen para que fuera una decisión consiente. No quería que omitieran ese paso y terminaran ingresando un tipo de examen distinto al que debían ingresar.

En las secciones con búsqueda de RUT (ingreso de paciente, búsqueda de exámenes y de informante), si no se encuentra a la persona, agregué un feedback visual:

Y también me preocupé de que en secciones sin resultados mostrara un mensaje:

Finalmente, la aplicación es responsive, así que se ve bien en dispositivos móviles:

Aspectos técnicos

Es una aplicación web estilo “Single page application” (SPA) construida con React (versión 17)
La interfaz utiliza el framework AntDesign.
El deploy fue realizado en vercel.

Cosas a mejorar

Por restricciones de tiempo, no alcancé a hacer estas cosas:

1) Agregar un “confirmar” el envío del examen. Al presionar “Enviar”, que aparezca toda la información que estás ingresando y que puedas confirmar el envío. De esa forma el que ingresa puede corroborar la información que está ingresando.

2) Descargar examen como PDF. Al ver un examen particular, poder descargar los resultados en formato PDF. Supongo que en algún momento querrían imprimir los resultados…

En cuanto a recursos FHIR utilizados, hay uno en particular que quizás debería ser incluido. Al enviar los resultados, crear un DiagnosticReport que incluya la información de la Observation que se está creando. Según la documentación, este tipo de recursos debe ser usado para representar exámenes de laboratorio.

Resultados del desafío

Luego de haber estado 3 días aprendiendo sobre este nuevo mundo y aplicándolo para crear una aplicación, logré tener el primer lugar 🎉

Mis impresiones sobre FHIR para la interoperabilidad

La versión utilizada de FHIR funciona con APIs REST en json. En español esto significa de que un programador web debería ser sencillo comprender la parte técnica de esto.

En mi caso fue así. Lo complicado es la terminología clínica y como mapear recursos con procesos de la vida real.

Otra complicación que veo es que si bien la forma de comunicación es estándar, pueden haber dificultades. Algunos ejemplos:

En el desafío avanzado, obtener a los apellidos de un prestador es distinto a obtener los de un paciente. En el caso del prestador, se utilizaba una extension. ¿Qué pasa si no todos los centros lo hacen así?
El estandard es peligrosamente flexible. Los resultados de un examen particular como el perfil lipídico podrían hacerse ingresando todo en un solo recurso Observation o crearse múltiples recursos.
Trabajar con el recurso Parameters para obtener unidades y rangos de referencia fue relamente tedioso 😂. El formato de los datos es más complicado de lo que podría ser aunque estoy seguro de que debe haber una razón para que sea así.

Dejando de lado las dificultades, como creador de software, lo que más me gusta es la posibilidad de crear aplicaciones que funcionen independiente de donde provengan los datos. Aplicaciones agnósticas a la fuente, pero que hablen en HL7, de manera que puedan ser utilizadas por cualquier centro o institución que use el estándar.

Estándares de interoperabilidad en salud

Eliana Quijada — Thu, 26 Nov 2020 18:00:00 GMT

En el post anterior ya mencionamos qué implica y qué beneficios podría tener el utilizar la interoperabilidad en salud. Pero además, es importante considerar que para que toda esa comunicación entre diferentes sistemas informáticos realmente funcione, y que la información compartida sea utilizada de forma eficiente, es necesario establecer reglas para que las diferentes instituciones “conversen” y sepan de qué están hablando.

Para permitir esta “conversación” se han establecido estándares de interoperabilidad, enfocados en unificar la información que es compartida.

Existen distintos tipos de estándares que pueden clasificarse según su funcionalidad. Por ejemplo, hay estándares de mensajería, terminología, documentos, entre otros.

Estándares de mensajería

Los estándares de mensajería establecen la estructura y el formato de la información compartida.

Un ejemplo común para poder entender el objetivo de estos estándares es pensar en una receta de medicamentos hecha en papel.

Habitualmente los talonarios de recetas institucionales tienen una serie de campos a completar por el médico, los cuales son indispensables para que la farmacia dispense el medicamento (como el nombre y rut del paciente, el diagnóstico, el medicamento, la dosis, la vía de administración, entre otros). Esta receta nos ayuda a establecer la estructura de la información que quiere comunicar el médico al químico farmacéutico, que finalmente autorizará la dispensación del medicamento. Si esta solicitud se hiciera escribiendo todos los datos en una hoja en blanco, el químico debería deducir a qué tipo de dato corresponde cada línea de información escrita.

Si esto lo llevamos a los sistemas informáticos, es necesario saber el contenido que tendrá cada mensaje enviado y/o recibido, para así poder decirle al sistema qué debe hacer específicamente.

Algunos ejemplos de estos estándares son:

HL7 v2: HL7 (Health Level Seven International) es una organización sin fines de lucro que se encarga de desarrollar estándares que permiten intercambiar información asociada a salud. Esta es la versión más utilizada actualmente en los sistemas de salud. Los mensajes de esta versión son algo difíciles de entender a simple vista, porque son varias líneas largas, que utilizan símbolos específicos para separar los datos.
HL7 v3: Esta versión intenta ser menos flexible que la anterior, ya que esta flexibilidad tiene altos costos que implican dificultades al intentar hacer integraciones o mantenciones de los sistemas. Este estándar además de mensajes incorpora también terminologías. Todas estas características hacen que la migración desde la versión anterior sea algo compleja.
DICOM: (Digital Imaging & Communications in Medicine). Es un estándar de transmisión de imágenes médicas y datos. Las aplicaciones más comunes de este estándar son la visualización, almacenamiento, impresión y transmisión de las imágenes.

Estándares de terminología

Estos estándares establecen conceptos comunes para referirnos al mismo diagnóstico, procedimiento, examen, síntoma, etc.

Aquí ya se intenta hilar un poquito más fino, ya que sabemos que es habitual utilizar diferentes terminologías para referirse a un mismo síntoma, diagnóstico, examen, observación o medicamento. Si necesitamos automatizar procesos, decisiones o análisis de los datos obtenidos, es muy importante que estén adecuadamente clasificados.

Algunos ejemplos son:

SNOMED-CT: (Systematized Nomenclature of Medicine – Clinical Terms) terminología clínica integral, multilingüe y codificada. Mantenida y distribuida por la International Health Terminology Standards Development Organisation (IHTSDO).
LOINC: (Logical Observation Identifiers Names and Codes) Es un estándar internacional que incluye identificadores, nombres y códigos para identificar mediciones de salud, observaciones y documentos. Se utiliza principalmente para exámenes de laboratorio.
CIE-10: (Clasificación internacional de enfermedades, 10.ª edición) es publicada por la Organización Mundial de la Salud (OMS). Determina la clasificación y codificación de las enfermedades y se ocupa principalmente para fines estadísticos relacionados con morbilidad y mortalidad.

Estándares de documentos

Indican qué información y cómo debería estructurarse en la generación de documentos clínicos tales como evoluciones clínicas, informes de exámenes o epicrisis.

Ejemplos de este tipo de estándar:

HL7 CDA: CDA es la abreviatura de Clinical Document Architecture. Está basado en la metodología de trabajo de HL7 V3. El objetivo de este estándar es definir la parte estructural y semántica del documento, pero no se ocupa del contenido de estos documentos.
CCR: (Continuity of Care Record) fue desarrollado conjuntamente por ASTM International, la Sociedad Médica de Massachusetts, la Sociedad de Sistemas de Gestión e Información de Salud (HIMSS), la Academia Estadounidense de Médicos de Familia y otros proveedores de informática de la salud. Es una forma de crear documentos flexibles que contienen la información médica básica más relevante y oportuna sobre un paciente y enviarlos electrónicamente de un cuidador a otro.

HL7 FHIR

FHIR significa Fast Healthcare Interoperability Resources. Le haré una mención por separado porque tiene como objetivo intentar abordar varios tipos de estándares, combinando características de HL7 v2, v3 y CDA.

Su funcionamiento se basa en el concepto de recursos, donde cada recurso es un bloque de información que representa un concepto de la atención clínica (como paciente, cita médica, prescripción de medicamentos, resultado de exámenes, etc). Y cada recurso puede ir relacionándose con otros, para por ejemplo asociar todas las citas médicas de un mismo paciente.

Intenta simplificar su implementación y aprendizaje utilizando arquitecturas más comunes para los desarrolladores como lo son los archivos en formato JSON o XML y la utilización API REST (Si no eres del área informática y estos conceptos te suenan a chino, es normal, pero en futuros posts planeo explicarlos con peras y manzanas, o mejor aún con píldoras y jeringas).

Personalmente tuvimos la oportunidad de jugar un poco con este estándar durante el TechConnect 2020, escribimos un post sobre nuestra experiencia.

Resumen

Existen variadas herramientas enfocadas a solucionar algunas de las brechas que se presentan para poder implementar sistemas interoperables, el desafío está en el diseñar, desarrollar e implementar sistemas informáticos que les saquen el mayor provecho posible.

Es cierto que existen muchas otras barreras para poder llegar a un punto ideal, pero tenemos la tecnología a nuestro servicio, sólo queda trabajar con ella y utilizarla para brindar una mejor atención de salud.

Algunas referencias

SNOMED-CT
LOINC
HL7 FHIR
Si están interesados conocer más detalles sobre cómo se construyen los estándares este post les puede ayudar Introducción a Interoperabilidad y estándares en salud
Aquí hay algunos detalles más técnicos de los diferentes estándares de HL7 Los 5 estándares HL7 fundamentales

Interoperabilidad en salud

Eliana Quijada — Tue, 17 Nov 2020 18:00:00 GMT

En la práctica clínica, es habitual que una vez atendido el paciente se guarden sus datos en los sistemas de registro clínico propios del centro de atención de salud. Esta información queda encapsulada, disponible para ser utilizada sólo cuando el paciente regrese al mismo centro.

Esta situación era, y aún sigue siendo, algo inherente a los registros en papel. Sin embargo, muchos sistemas clínicos electrónicos replican este patrón a pesar de que una de las ventajas que nos brinda tener la información digitalizada es que no es necesario estar en el mismo lugar físico para acceder a ella (gracias al mágico internet).

La interoperabilidad en salud tiene como objetivo evitar que existan todas estas “islas de información”, ya sea dentro de una misma institución como en diferentes instituciones.

Pero, ¿qué beneficios tiene esta posibilidad?

La interoperabilidad en salud permite mejorar la calidad y seguridad de la atención brindada a nuestros pacientes.

Para explicar esta afirmación describiré algunos ejemplos de situaciones que me tocaba visualizar en el día a día de la atención clínica:

Situación 1: pacientes con enfermedades crónicas

Es muy habitual, sobre todo en el caso de los pacientes con enfermedades crónicas, que ellos o sus cuidadores tengan una carpeta, un cuaderno o un gran sobre, en donde van archivando uno a uno todos los exámenes y resúmenes de cada atención que reciben. Esto abre la posibilidad de que se pierdan, se dañen, o que simplemente en una situación de emergencia los olviden en casa.

Al trabajar bajo el concepto de interoperabilidad, la institución prestadora podría consultar los resúmenes de las atenciones que el paciente ha recibido previamente y de esta manera evitar que sea el paciente el único responsable de portar con su información clínica.

Situación 2: derivación de pacientes

A veces un profesional debe realizar la derivación de un paciente a otro profesional que trabaja en un centro de atención diferente.

Para que esta derivación se realice, pueden existir conductos regulares que exigen completar formularios oficiales. Muchas veces es el paciente o un familiar el encargado de trasladar este documento desde las manos del profesional que deriva hasta la oficina encargada de recibir la interconsulta.

Similar a la situación anterior, que exista la forma de comunicar los datos ingresados por el primer profesional al segundo, permitiría evitar que sea el paciente o su familiar el responsable de trasladar esta hoja de papel. Esto es muy relevante considerando que hay traslados que pueden realizarse entre regiones.

Situación 3: registros clínicos y administrativos

Cuando trabajaba en un servicio de hospitalizados, cada mañana antes de entregar turno, debíamos obtener los resultados de los exámenes de laboratorio pertenecientes a nuestros pacientes desde el sistema informático del laboratorio del hospital. Parte del flujo que debían seguir estos resultados era:

La enfermera clínica los transcribía a mano a la hoja de enfermería diaria
La enfermera clínica los ingresaba a la entrega de turno realizada en un documento digital
El médico que entregaba turno debía ingresarlos en su entrega de turno digital
El médico que recibía turno debía transcribirlos a la evolución médica diaria

Y como si todo esto fuera poco, cuando debíamos realizar seguimientos destinados a medir estándares de calidad, teníamos que ingresar algunos de estos resultados a la planilla excel que mensualmente solicitaba la unidad de Infecciones Asociadas a la Atención de Salud (IAAS).

Este pequeño ejemplo práctico muestra uno de los muchos puntos de la atención que se vería beneficiado de sistemas de registro clínico informático que “conversen” entre sí, evitando los múltiples ingresos de la misma información, lo que a su vez reduce el riesgo de errores y también el tiempo del personal clínico utilizado en labores diferentes a la atención directa del paciente.

Estándares de interoperabilidad

Si consideramos la interoperabilidad como un proceso comunicativo, es muy importante que además de tener un canal para poder transmitir la información, también se utilice un lenguaje en común que sea comprensible para todos los participantes del proceso. De esta forma, todos los sistemas involucrados podrán interpretarlos, almacenarlos y mostrarlos.

Para poder cumplir este objetivo, se originaron los estándares de interoperabilidad. Tema que hablaremos en las próximas entradas del blog.