Empezar desde una observación incómoda
Sinceramente, hasta donde podemos ver, muy pocas empresas de software clínico están publicando hoy una función de "cuestionario estructurado de síntomas preconsulta". iRehab, desde Taiwán, es una de ellas. No encontramos muchos pares, ni en Taiwán ni internacionalmente, construyendo exactamente esto.
¿Significa eso que el problema todavía no existe? No: significa que el problema está a punto de aparecer.
Si miramos la historia de la tecnología médica, el patrón se repite: cada hospital o red sanitaria construye su propio EHR / HIS, las estructuras no interoperan y luego aparecen décadas de deuda de integración. En España, por ejemplo, la Receta Electrónica del SNS empezó a desplegarse alrededor de 2003 y necesitó más de 15 años para alcanzar una interoperabilidad real entre comunidades autónomas. En México, el Expediente Clínico Electrónico existe como mandato y aspiración normativa, pero la distancia entre el marco formal y la realidad operativa sigue siendo grande en muchas instituciones. Argentina y Chile viven variaciones del mismo problema: iniciativas nacionales, provincias o redes con ritmos distintos, proveedores heterogéneos y una brecha persistente entre digitalizar y hacer interoperable.
Si la "captura estructurada preconsulta" se convierte en la próxima función ubicua del software clínico — y la proliferación de AI hace que eso sea muy probable — el mismo patrón de fragmentación se puede repetir:
- Cada proveedor construye su propio formato durante los primeros 3 años
- La presión competitiva fuerza conversaciones de estandarización hacia los años 5-7
- Pero para entonces los esquemas internos ya están calcificados, la deuda de integración está acumulada y los costes de migración son prohibitivos
Cuando mapeamos esta trayectoria contra los actores que terminarían preocupándose por ella — proveedores HIS, plataformas de agenda, sociedades clínicas, especialistas individuales, autores académicos, socios de dispositivos médicos y seguros privados — apareció un patrón. Cada grupo acabaría necesitando un formato. Pero bajo un régimen de comienzo cerrado (proprietary), cada ruta de colaboración es lenta, cara y con mucha fricción para ambas partes.
Una sola empresa necesitaría 10 veces más recursos para hacerlo mediante desarrollo de negocio bilateral, y aun así probablemente fracasaría.
Así que, en lugar de esperar a que todos reinventen el formato y luego negocien, ponemos ahora un formato de referencia sobre la mesa como punto de partida para esa conversación.
Puede que esta guía no se convierta en el estándar final. Pero sí mueve la discusión al lugar correcto.
Un marco: distribuidor vs motor
Si desmontamos la función Brief, aparecen dos capas.
La capa de "formato" es el esquema de formato (schema) JSON, las definiciones de campos y los puntos de activación de módulos de alerta clínica. Técnicamente no es algo extraordinario. Cualquiera que haya leído la especificación FHIR Questionnaire puede reproducir esta capa en un fin de semana.
La capa de "lógica" es donde vive el trabajo real: cómo juzga el pipeline de red flags (umbrales, ponderaciones, texto de escalamiento), cómo se diseñan y afinan los prompts de integración AI SOAP, cómo se acumula el corpus de anulaciones del médico, cómo el editor Composer diseña la experiencia de autoría para el clínico.
Históricamente estas dos capas se han vendido juntas, porque el instinto SaaS es "venderlo todo". Pero empaquetarlo todo tiene un coste: cada proveedor HIS que quiera soportar tu formato de forma nativa debe firmar licencias, pagar regalías y pasar revisión legal. La fricción es demasiado alta; nadie se molesta.
En el momento en que separas las dos capas, la estrategia se vuelve clara:
El formato puede ser abierto. La lógica permanece cerrada para siempre.
El formato es el distribuidor. La lógica es el motor. Mantén cerrado el motor como foso comercial; libera gratis el distribuidor como multiplicador de adopción.
Qué desbloquea abrir el formato
Una vez que el formato es público, los siguientes eventos se vuelven estructuralmente posibles. No solo más fáciles: bajo términos cerrados simplemente no ocurren.
- Los proveedores HIS pueden leer el esquema e integrarlo de forma nativa: sin NDA, sin regalías, sin revisión legal previa
- Las plataformas de terceros pueden implementar reciprocidad de formato: "tu cuestionario y el mío pueden leerse con el mismo parser", algo imposible en un régimen cerrado
- Médicos externos pueden contribuir paquetes de especialidad mediante pull requests — ginecología y obstetricia, neurología, psiquiatría, rehabilitación, medicina familiar — abriendo un canal de contribución que no existe en código cerrado
- Los trabajos académicos pueden citar el esquema como un estándar citable
Cada una de estas vías costaría 10 veces más mediante desarrollo de negocio bilateral, con una tasa alta de fracaso. Abrir el formato convierte "tenemos que empujar" en "pueden venir".
Qué queda cerrado — para siempre
La frontera debe ser explícita. Sin ella, una estrategia open-core se expone fácilmente a la crítica de "simplemente todavía no han abierto suficiente".
Los siguientes seis componentes nunca entrarán en este repositorio, como queda documentado en LICENSE_STRATEGY.md §6:
- Lógica interna del pipeline de red flags (umbrales, ponderaciones, algoritmos de puntuación, reglas de composición entre preguntas, texto de escalamiento) — esto es lógica de decisión médica; abrirla elimina la compuerta de calidad y además es nuestro verdadero foso
- Prompts y ajuste fino de la integración AI SOAP — la ingeniería de prompts es propiedad intelectual comercial en evolución continua
- Código de manejo de PII del paciente — el cumplimiento de privacidad no se toca a la ligera; cualquier modificación open-source exige auditoría de cumplimiento
- UI / UX de iRehab Doctor PWA — el diseño del flujo de trabajo es diferenciación comercial
- Pipeline de datos del outcome registry — núcleo de la línea de ingresos B2B
- Composer, el editor gráfico para crear esquemas — una diferencia clave en la experiencia del médico
Más importante aún: las necesidades de cada clínica, hospital o proveedor de servicios en estas áreas varían demasiado. No creemos que estas decisiones deban centralizarse en un solo proveedor. Dejarlas a cada organización, y a su propia AI, es un diseño más sano.
Estructura de doble licencia
| Contenido | Licencia |
|---|---|
Archivos de esquema (spec/v0.1/schema/*.json), código del validador | Apache-2.0 con cláusula de concesión de patente (patent grant) |
| Documentos de especificación, ejemplos, tutoriales, README | CC BY 4.0, que permite uso comercial, adaptación y redistribución con atribución |
Las dos licencias no son intercambiables: al citar o reutilizar, aplica la licencia correcta según el tipo de archivo.
La combinación es deliberada. La cláusula explícita de concesión de patente de Apache-2.0 da una protección fuerte a proveedores HIS y plataformas de terceros que adopten el validador del esquema. CC BY 4.0 es el estándar internacional más familiar para contenido abierto y para citación académica.
Por qué la ley aplicable es la de la República de China (Taiwán)
El licenciante es una empresa taiwanesa: De Novo Orthopedics 谷盺生物科技股份有限公司. Las marcas están registradas en Taiwán: "iRehab 愛復健 with logo" cubre las clases Nice 9/10/35/44; "DE NOVO ORTHOPEDICS / 谷盺生物科技" cubre 5/9/10/35/42/44. La responsabilidad y la resolución de disputas fluyen de forma más directa por Taiwán.
La declaración está en el repositorio y en el README. No modifica los textos de Apache-2.0 ni de CC BY 4.0, ya que ambas licencias prohíben modificar sus textos. Funciona como una declaración separada de ley aplicable del licenciante, que acompaña a las licencias subyacentes sin alterarlas. Tribunal de primera instancia: Taichung District Court, donde está registrada De Novo Orthopedics.
Ver docs/governing-law.md para la declaración completa.
26 conclusiones predraft confirmadas por abogados
Antes de publicar, redactamos cuatro grupos de opiniones jurídicas predraft:
- Grupo A: Personal Data Protection Act (9 conclusiones)
- Grupo B: Electronic Medical Records and Medical Care Act (6 conclusiones)
- Grupo C: licencias open-source y propiedad intelectual (8 conclusiones)
- Grupo D: Personal Data Protection Commission y temas misceláneos (3 conclusiones)
Nuestro abogado externo confirmó el 2026-05-06: 26/26 conclusiones confirmadas, 0 correcciones requeridas.
Esto no significa "riesgo cero". Significa que el diseño actual se sostiene bajo el marco legal vigente de Taiwán. El único punto "por suplementar" es D-1c: un Personal Data File Security Maintenance Plan escrito, documento interno de respaldo para auditoría. No es público y no bloquea la publicación.
La señal para proveedores HIS, plataformas de terceros y sociedades clínicas es esta: la base legal de este repositorio fue realmente revisada por abogados; no fue publicada solo por entusiasmo.
El flujo de trabajo más directo para médicos
Si eres médico y estás leyendo esto pensando "qué puedo hacer realmente con esto", el flujo más directo es:
Entrega este URL de GitHub a tu asistente de AI — ChatGPT / Claude / Gemini / Microsoft Copilot — y pídele que haga lo siguiente:- Diseñar un brief preconsulta estructurado de 8-10 preguntas para tu especialidad: ginecología y obstetricia, neurología, psiquiatría, medicina familiar, urgencias, pediatría, cardiología…
- Convertir tu cuestionario actual en papel en un brief JSON compatible con este esquema.
- Planificar cómo integrar el brief en los sistemas de tu consulta, hospital o red asistencial.
No se requiere ingeniería. Una vez que la AI tenga el URL del repositorio, leerá por su cuenta spec/v0.1/authoring-spec.md, examples/orthopedics-complete.json, docs/overview.md y docs/for-doctors.md; luego te guiará paso a paso por el diseño y producirá un archivo JSON utilizable.
En entornos de cumplimiento, usa un LLM local. Muchos hospitales — en España bajo GDPR, en México bajo marcos de protección de datos personales y en instituciones privadas de América Latina con políticas internas estrictas — prohíben enviar contenido clínico a servicios externos de AI. Pero "diseñar un formato de cuestionario" no involucra datos de pacientes: el esquema es público, y lo que recibe la AI es una guía de formato más las necesidades de tu especialidad. El flujo puede mantenerse compatible incluso en entornos estrictos. Opciones: Azure OpenAI en un tenant hospitalario, Ollama en un servidor local, o un LLM interno provisto por el proveedor HIS. Microsoft tiene una de las estrategias más agresivas de despliegue compatible en hospitales; si tu institución ya usa Microsoft 365 / Azure, Copilot probablemente ya pasa por canales de cumplimiento. Confírmalo con tu departamento de TI.
Algunos prompts de ejemplo:
"Soy psiquiatra; mis consultas externas son predominantemente ansiedad, insomnio y trastornos del ánimo. Usando la especificación en https://github.com/Denovortho/open-irehab-brief-schema, diseña un brief preconsulta estructurado de 8-10 preguntas que produzca JSON válido conforme a brief-template.schema.json. Cubre el territorio clínico de PHQ-9 / GAD-7 en espíritu, pero no transcribas directamente esos instrumentos."
"Tengo un cuestionario preoperatorio en papel de 12 preguntas, adjunto como imagen. Conviértelo a JSON iRehab Brief Schema v0.1 (repo: https://github.com/Denovortho/open-irehab-brief-schema). Preserva la intención original, estructura donde sea posible y asegura i18n con al menos zh-TW + en."
El primer intento no será perfecto, pero te permite empezar hoy, en lugar de esperar a "un ingeniero / un presupuesto / un ciclo de TI".
Repo + Releases
- Repository:
github.com/Denovortho/open-irehab-brief-schema - v0.1.0 release (spec only):
releases/tag/v0.1.0 - v0.1.1 release (con JSON Schema + 2 ejemplos + overview):
releases/tag/v0.1.1
Diez archivos: especificación, doble licencia, ley aplicable de Taiwán y rastro de opiniones jurídicas.
Qué sigue
- Validador de referencia (Apache-2.0): objetivo v0.2, aplicará reglas entre campos (cross-field rules)
- Más ejemplos por especialidad: contribuciones de la comunidad bienvenidas vía PR
- Documentación de patrones de integración HIS
- Implementación de referencia del receptor de webhooks
- v1.0 stable release: objetivo 2026 Q4, activa el compromiso de compatibilidad hacia adelante (forward compatibility)
Si quieres contribuir un paquete de especialidad para tu campo, consulta CONTRIBUTING.md para ver el proceso.
Para integración comercial, licencias o consultas de marca: service@denovortho.com
Por qué importa
No porque "open source = bueno".
Importa porque la historia de cada hospital escribiendo su propio HIS, y las décadas de deuda de integración que siguieron, no debería repetirse. El dolor de intercambiar historias clínicas entre hospitales, el tiempo que toma incorporar una nueva institución a cualquier red sanitaria, el coste lateral de cambiar de proveedor: todo eso es el precio de haber dejado crecer la fragmentación inicial sin control. España lo vivió con la interoperabilidad entre comunidades autónomas; México lo vive con la brecha entre mandato de Expediente Clínico Electrónico y adopción real; muchas redes privadas de América Latina lo viven cada vez que una adquisición, convenio o integración exige mapear datos clínicos a mano. Si la captura estructurada preconsulta sigue el mismo camino, en 2035 estaremos teniendo la conversación de estandarización que deberíamos tener ahora, con otra década de deuda acumulada.
Y no porque "open source = generosidad".
Importa porque la entidad que pone primero el formato sobre la mesa suele terminar, vista en retrospectiva, como quien define el estándar de ese dominio. HTTP — Tim Berners-Lee lo liberó —, TCP/IP — Vint Cerf y Bob Kahn lo publicaron —, FHIR — HL7 lo publicó — no ganaron por maximizar el precio de venta. Ganaron por dejar el formato públicamente visible desde el principio.
Puede que no acabemos ocupando esa posición. Pero hoy estamos poniendo una propuesta sobre la mesa para ver si puede convertirse en un punto de partida común.
Si también crees que la captura estructurada preconsulta merece un formato común, damos la bienvenida a críticas, citas, forks y pull requests. También damos la bienvenida a objeciones contra nuestras decisiones de diseño: el propósito completo de la especificación es poner esas decisiones sobre la mesa para debatirlas.
Lecturas adicionales
Estándares internacionales y licencias
- HL7 FHIR Questionnaire — HL7 FHIR R5 Questionnaire Resource. El mismo dominio de problema, con mayor alcance y más complejidad. Vale la pena comparar las decisiones de diseño.
- Apache License 2.0 texto completo — Apache Software Foundation. Incluye la cláusula de concesión de patente. Es la licencia usada para el esquema y el código del validador en este repositorio.
- Creative Commons CC BY 4.0 texto completo — Creative Commons. El estándar internacional para licenciar contenido abierto. Usado para documentos de especificación y ejemplos en este repositorio.
Precedentes históricos de estándares abiertos
- Berners-Lee, T. (1989). Information Management: A Proposal. CERN. — El memorando original que propuso la Web, luego liberado sin regalías como estándar abierto.
- Cerf, V., & Kahn, R. (1974). A Protocol for Packet Network Intercommunication. IEEE Transactions on Communications. — El artículo fundacional de TCP/IP que hizo posible la interoperabilidad de internet moderno.
- Mandl, K. D. & Kohane, I. S. (2012). Escaping the EHR Trap — The Future of Health IT. NEJM. — Dos especialistas de Harvard en informática médica sobre por qué la fragmentación histórica de los EHR tiene costes de largo plazo que todavía seguimos pagando.
Publicaciones relacionadas en el blog de De Novo
- Design Thinking in the AI Age: From Bottleneck to Multiplier — El editor Composer, la interfaz de autoría detrás de esta guía de esquema, es producto de un giro reciente desde un piloto de una sola especialidad hacia una herramienta transversal. Este texto recorre ese proceso.
- When AI Brings Software Cost to Zero — Implantable Sensors, Thick Software, and Where the Real Moat Lives — Un argumento hermano de "distribuidor vs motor": qué capas se comoditizan, cuáles no y cómo valorar cada una.
- Compress the Visit, Don't Integrate the Form: The Design Logic of iRehab Doctor AI — El diseño de cadena de responsabilidad detrás de la integración AI SOAP en Brief: la AI traduce, el médico valida, las responsabilidades no se mezclan. Por qué esta capa permanece dentro del límite §6 cerrado para siempre.
- 30-Second Daily Check-in — Designing Rehab Software for 80-Year-Olds — Otro problema de "entrada clínica estructurada", en una etapa distinta: preconsulta versus seguimiento continuo de rehabilitación. Un contraste útil sobre decisiones de diseño.