Skip to content

OLD roadmap in spanish

Pablo Pazos Gutiérrez edited this page Nov 21, 2017 · 1 revision
  • El XML de la composition en /compositions debería ser válido contra el XSD de composition:

    • en lugar de empezar con debería empezar con
  • Índice del contenido de las compositions XML

    • extraer las paths válidas desde el arquetipo referenciado por la composition
    • extraer las gpaths desde el arquetipo (para extraer datos directamente)
    • mapear ambas cosas en una bd relacional, incluir el valor en cada path
    • cada valor se guarda en una tabla específica para cada tipo de dato, así una consulta obtiene valores para cada tipo de dato con su propia estructura
    • las consultas se podrían hacer por path o gpath, siempre sobre los índices, nunca sobre los XMLs.
    • si no hay valor para una path (cuando se está indizando) no se agrega la referencia (se busca solo en los valores que existen)
    • los índices deben tener un puntero a la composition a la que pertenecen, así puedo hacer consultas por condiciones en los valores, y obtener un set de compositions que matcheen.
    • COMPOSITION.context tambien se indexa (es el índice de nivel 1 porque sirve para buscar documentos por fecha, tipo/arquetipo, autor, categoría, paciente, )

==== ROADMAP ====

  • Query builder & tester:

    • Poder diseñar queries desde UI
    • Poder probarlas contra sets de datos de ejemplo que se commiteen para esa query
      • generando también pacientes y EHRs según sea necesario
      • que la generación sea paramétrica (cuántos pacientes/EHRs)
    • Poder guardar la query con un nombre/id para que sea ejecutada luego
    • La ejecución debe tener en cuenta los parámetros de la query y solicitarlos (ej. desde la UI de prueba o verificar que vienen los parámetros obligatorios desde invocación por servicio)
  • Trazabilidad también para consultas (logs)

    • Quién accede, desde qué lugar y a qué registros
    • Qué consultas se hicieron
    • Cuándo se accedió y cuánto demoró (para medir tiempos en estadísticas y poder mejorar performance)
  • Servicio de replicación:

    • Alta disponibilidad
      • que con configuración de un proxy se pueda distribuir la carga entre distintas réplicas
      • que ante la falla de un servidor, otro tome el lugar
    • Seguridad
      • respaldo automático de registros clínicos
  • Gestión de EHRStatus:

    • Importa si el EHR es consultable y si es modificable
    • Se debe verificar en query y en commit respectivamente
  • Gestión de permisos:

    • definición de permisos a nivel de aplicación usando rangos de ip, puertos y servicios a los que puede acceder en el EHR.
    • haciendo un envelope de los mensajes se podría verificar id del sistema origen y otros datos
  • Gestión de folders:

    • Crear, mover, eliminar folders
    • Toda acción debe estar logueada para audit
    • Poner registros en folders de forma manual (gestión de registros clínicos)
    • Creación de reglas de copia de registros commiteados a folders
      • Para ubicación / ruteo automático de compositions a folders en el commit
      • Una compo puede ir a más de un folder
      • Reglas por datos demográficos, tipos de registro (archId), fecha, contenido (ej. un arquetipo interno como diagnóstico/problema de salud)
  • Merge de EHRs

  • Encriptacion de documentos en fs