ppazos / open-ehr-gen-framework Goto Github PK

El binder no debería procesar slots porque debería tener predefinida una 
estructura de arquetipo completa, por ejemplo un template debería representar 
una estructura de arquetipo completa, aunque los arquetipos referenciados desde 
el temaplate tengan slots. El template debería indicar, para cada slot de cada 
arquetipo que se use, qué arquetipos específicos se cargan en cada slot 
(recordar que los slots pueden referenciar múltiples arquetipos de forma 
genérica, pero el template debería indicar cuáles específicamente se van a 
usar).

Luego el binder debería usar la definición completa, o sea el template. Ahora 
como está hecho, el binder recorre desde el arquetipo raíz, para abajo hacia 
arquetipos referenciados por slots. Entonces el cambio sería que debería 
recorrer el template, luego cada arquetipo referenciado, y cuando se encuentra 
un slot, se vuelve al template donde se indica que arquetipos se deben recorrer 
para ese slot luego, y se sigue la recorrida, uniendo todas las partes del RM 
generado, sin necesidad de dejar referencias a los slots y de unir las 
estructuras parciales al final, como se hace ahora.

Al intentar editar un formulario que ya fue guardado, el cual contiene un 
arquetipo que posee una entrada la cual puede tener multiples ocurrencias, la 
aplicación deja editar las ocurrencias guardadas (para la entrada) pero no 
deja agregar nuevas.

Muchas vistas tienen textos hardcoded.
Muchos mensajes de flash de los controllers estan hardcoded.
Hay algunas traducciones que no están hechas.

Hacer una revisión general y hacer las traducciones.

En el arquetipo de presión arterial tenemos un cluster opcional con 2 elements.

La idea es probar el binder/validador cuando el cluster es obligatorio y no se 
ingresan datos para alguno de los elements. Este es el arquetipo hoy:


OBSERVATION[at0000] matches {   -- Presión arterial
    data matches {
        HISTORY[at0001] matches {   -- Event Series
            events cardinality matches {1..*; unordered} matches {
                EVENT[at0002] occurrences matches {0..1} matches {  -- Cualquier evento
                    data matches {
                        ITEM_TREE[at0003] matches { -- Lista
                            items cardinality matches {0..*; unordered} matches {
                                CLUSTER[at0005] occurrences matches {0..1} matches {    -- Presión arterial

El codigo del template tiene un bug y fue solucionado por nosotros para poder 
generar dinamicamente la gui de la hce.

Es necesario introducir el codigo del plugin como parte del framework para 
quitar la dependencia al plugin, y al codigo con bugs, sino cada usuario 
debería corregir el mismo bug para que funcione correctamente.

Debe solucionarse para v0.6.

El problema es que si pongo valores intercalados, tal como se muestra en la 
primer imagen adjunta, luego de guardar los datos, en el show se muestra el 
primer valor repetido, donde no se había ingresado dato.

Puede ser problema del script de show, o de la limpieza de params vacíos en el 
save.

Al intentar guardar información incorrecta en un formulario, por ejemplo un 
entero fuera de rango o vacio un campo obligatorio, salta el siguiente error:

Error 500: groovy.lang.MissingPropertyException: No such property: templateId 
for class: hce.GuiGenController
Servlet: grails
URI: /ehr/grails/guiGen/save.dispatch
Exception Message: No such property: templateId for class: hce.GuiGenController
Caused by: groovy.lang.MissingPropertyException: No such property: templateId 
for class: hce.GuiGenController
Class: GuiGenController
At Line: [496] 

Solo se ve el código CIE10 del diagnóstico pero no el texto, y debería 
mostrar el texto también. ¿pasará esto con todos los coded text o es solo 
con los diagnósticos?

La primer mejora a la creación de registros sería que al hacer clic en "Nuevo 
registro", en lugar de cargar una nueva página, aparezca como ventana modal, 
en el mismo listado de registros, la creación del nuevo registro. Con esto se 
ahorra cargar una nueva página y un paso en el flujo de trabajo.

Por otro lado, la creación de un registro, para el ambulatorio, se podría 
hacer seleccionando un paciente de la lista de espera/agenda de turnos del 
médico. Por lo que se podría implementar un pequeño plugin para mostrar la 
lista de turnos que tiene el médico.

La tercer forma de crear registros es mediante servicios, es decir que el 
sistema provea un WS para que otros sistemas puedan crear registros, por 
ejemplo en el ambulatorio, cuando el paciente paga su orden y viene a la 
atención, el sistema de agenda podría crear un nuevo registro, con el 
paciente ya identificado. De esta forma, el médico en lugar de crear el 
registro, abre los registros que tiene creados para los turnos del día actual.

Si uno tiene un dominio seleccionado, al acceder a http://localhost:8080/ehr/
se muestra el listado de registros de ese dominio, y esperaba ver el listado de 
dominios.

Cambiar el concepto de Episodio por el de Registro. Episodio quedó de 
traumagen porque eran registros episódicos. El framework debe manejar 
registros generales, tanto episódicos como continuos.

Tengo una observaton con un cluster obligatorio y multiple. El cluster tiene 2 
elements, cada uno con un DvQuantity:

OBSERVATION[at0000] matches {   -- test cluster obligatorio multiple struct
    data matches {
        HISTORY[at0001] matches {   -- Event Series
            events cardinality matches {1..*; unordered} matches {
                EVENT[at0002] occurrences matches {0..1} matches {  -- Cualquier evento
                    data matches {
                        ITEM_TREE[at0003] matches { -- Arbol
                            items cardinality matches {1..*; unordered} matches {
                                CLUSTER[at0004] occurrences matches {1..*} matches {    -- cluster


Al clonar el CLUSTER (como en la captura adjunta), y sin ingresar datos se hace 
"Guardar", me aparecen errores para los DvQuantity de que se necesita que 
ingrese la unidad y la magnitud.
Como los ELEMENT son opcionales, si no se ingresan datos, no debería dar error 
en los DvQuantity.
Por otro lado, los errores deberían ser para los 6 DvQuantity que hay 
ingresados, y aparecen 4 errores iguales, pero se ponen para los DvQuantity del 
primer CLUSTER (ahí debe haber algo mal con el Javascript que pone los errores 
en el EDIT).


==============================================
bindELEMENT pathValor: 
[/data[at0001]/events[at0002]/data[at0003]/items[at0004]/items[at0005]/value/mag
nitude:, /data[at0001]/events[at0002]/data[at00
03]/items[at0004]/items[at0005]/value/units:]
bondElement: rmobjectForValue=[data_types.quantity.DvQuantity@533fc3]
Element Null ERROR Count :1
rmObjectsForValue.size :1
==============================================
bindELEMENT pathValor: 
[/data[at0001]/events[at0002]/data[at0003]/items[at0004]/items[at0006]/value/mag
nitude:, /data[at0001]/events[at0002]/data[at00
03]/items[at0004]/items[at0006]/value/units:]
bondElement: rmobjectForValue=[data_types.quantity.DvQuantity@15b8e6c]
Element Null ERROR Count :1
rmObjectsForValue.size :1
==============================================
bindELEMENT pathValor: 
[/data[at0001]/events[at0002]/data[at0003]/items[at0004]/items[at0005]/value/mag
nitude:, /data[at0001]/events[at0002]/data[at00
03]/items[at0004]/items[at0005]/value/units:]
bondElement: rmobjectForValue=[data_types.quantity.DvQuantity@1279e56]
Element Null ERROR Count :1
rmObjectsForValue.size :1
==============================================
bindELEMENT pathValor: 
[/data[at0001]/events[at0002]/data[at0003]/items[at0004]/items[at0006]/value/mag
nitude:, /data[at0001]/events[at0002]/data[at00
03]/items[at0004]/items[at0006]/value/units:]
bondElement: rmobjectForValue=[data_types.quantity.DvQuantity@295593]
Element Null ERROR Count :1
rmObjectsForValue.size :1
==============================================
bindELEMENT pathValor: 
[/data[at0001]/events[at0002]/data[at0003]/items[at0004]/items[at0005]/value/mag
nitude:, /data[at0001]/events[at0002]/data[at00
03]/items[at0004]/items[at0005]/value/units:]
bondElement: rmobjectForValue=[data_types.quantity.DvQuantity@1adbf85]
Element Null ERROR Count :1
rmObjectsForValue.size :1
==============================================
bindELEMENT pathValor: 
[/data[at0001]/events[at0002]/data[at0003]/items[at0004]/items[at0006]/value/mag
nitude:, /data[at0001]/events[at0002]/data[at00
03]/items[at0004]/items[at0006]/value/units:]
bondElement: rmobjectForValue=[data_types.quantity.DvQuantity@12563c6]
Element Null ERROR Count :1
rmObjectsForValue.size :1
bindCComplexObject rmObject tiene errores: 
org.springframework.validation.BeanPropertyBindingResult: 1 errors
Field error in object 'hce.core.datastructure.itemstructure.ItemTree' on field 
'items': rejected value [[]]; codes [ITEM_TREE.error.cardinality.hce.co
re.datastructure.itemstructure.ItemTree.items,ITEM_TREE.error.cardinality.items,
ITEM_TREE.error.cardinality.java.util.List,ITEM_TREE.error.cardinality
]; arguments []; default message [null]
Template: TEST-cluster_obligatorio_multiple_struct esta en cache << 
templates.tom.Template@1fda160 >>
Template: TEST-cluster_obligatorio_multiple_struct esta en cache << 
templates.tom.Template@1fda160 >>
Hay errors en el binder (bandera errors en true)

Hoy en el show del registro ingresado, no aparecen las preguntas para los 
campos que no tienen un valor ingresado. Es útil tener una configuración que 
permita indicar si se quieren ver solo las preguntas con valor asignado, o si 
se quieren ver todas las preguntas aunque no tengan valor.

Crear una acción en records para ver los registros de un mismo paciente, de 
distintos dominios, integrados en una misma vista. Esta vista podría servir 
incluso para integrar CDAs que el sistema reciba para el mismo paciente.

Para poder crear registros para pacientes que ya fueron admitidos en un sistema 
externo, se debería proveer un servicio de notificación, así el sistema 
externo puede decirle a la HCE que tal paciente ya fue admitido, y cuando lo 
toque su turno, el médico tendrá la información patronímica del paciente y 
le podrá abrir un registros clínico.

Hay pila de métodos que hacen bind, que al procesar lo que reciben preguntan 
si es una lista y hacen un procesamiento si es una lista o si no.
La correccion es que siempre se devuelva una lista de Locatable, para no 
preguntar más por el tipo, y que siempre se procese de la misma forma, aunque 
tenga un solo elemento.

A medida que avanza el proceso de atención, el registro clínico pasa por 
distintos estados, que quedan almacenados en distintas instancias de la clase 
VERSION del modelo de información de openEHR.

Estados posibles:

    * STATE_INCOMPLETE: registro incompleto.
    * STATE_COMPLETE: registro completo (proceso clínico cerrado, y el paciente correctamente identificado).
    * STATE_SIGNED: registro firmado.
    * Se guarda en version.lifecycleState 

En Version.data se guarda la referencia a la Composition para la cual se define 
el estado, de esta forma, habría varias instancias de Version para la misma 
instancia de Composition.

*Hoy se tiene solo una instancia de Version para una Composition, 
sobreescribiendo el estado, por lo que no se tiene la traza de cambios de 
estados. Esto se debe corregir.*

Para los listados de términos codificados que tienen cientos o miles de 
códigos, ponerlos dentro de un arquetipo no es viable, entonces se pone una 
restricción en un nodo CodedText con una referencia externa.

Hoy eso solo funciona para los códigos CIE10 de trauma, para lo que hay un 
binder, un buscador de códigos (llamado por ajax), y un generador de GUI todos 
custom.

La idea sería empezar generalizando esta GUI, incluso que no sea una vista 
aparte, sino que pueda ser un control que se genere como parte de una vista 
más compleja (y generada por el GuiGen). Lo segundo es que la búsqueda por 
ajax también pueda ser genérica, dependiendo de un parámetro a definir se 
buscaría en una lista de términos o en otra. Por último el binder debería 
poder hacerse de forma automática con lo que hay hoy implementado.

Aquí se propuso una solución: 
http://grails.1312388.n4.nabble.com/Best-way-to-cache-some-domain-objects-in-a-u
ser-session-td3828604.html#none

El problema a resolver es no tener que hacer una consulta en cada request de 
objetos que se necesitan para armar varias vistas, como el registro actual, el 
dominio, el paciente, el usuario logueado, etc.

Esto puede mejorar la performance y bajar las transacciones con la base de 
datos.

Hoy se muestran datos del registro pero no de los participantes, es útil para 
entrar al registro correcto.

Debe hacerse para v0.7.

Tengo el siguiente arquetipo:

OBSERVATION[at0000] matches {   -- test cluster obligatorio multiple
    data matches {
        HISTORY[at0001] matches {   -- Event Series
            events cardinality matches {1..*; unordered} matches {
                EVENT[at0002] occurrences matches {0..1} matches {  -- Cualquier evento
                    data matches {
                        ITEM_TREE[at0003] matches { -- Arbol
                            items cardinality matches {1..*; unordered} matches {
                                CLUSTER[at0004] occurrences matches {1..*} matches {    -- cluster
                                    items cardinality matches {0..*; unordered} matches {
                                        ELEMENT[at0006] occurrences matches {0..1} matches {    -- boolean
                                            value matches {
                                                DV_BOOLEAN matches {
                                                    value matches {True, False}
                                                }
                                            }
                                        }
                                        ELEMENT[at0005] occurrences matches {0..1} matches {    -- text
                                            value matches {
                                                DV_TEXT matches {*}
                                            }
                                        }


En la pantalla agrego 3 clusters, y si no ingreso datos en sus elements, me da 
un error de validacion, pero no me muestra ningun error en pantalla (ver 
adjunto).

En consola me tira:

==============================================
bindELEMENT pathValor: 
[/data[at0001]/events[at0002]/data[at0003]/items[at0004]/items[at0006]/value/val
ue:]
No valida DvBoolean value:
bondElement: rmobjectForValue=[data_types.basic.DvBoolean@1e5295a]
Element Null ERROR Count :1
rmObjectsForValue.size :1
==============================================
bindELEMENT pathValor: 
[/data[at0001]/events[at0002]/data[at0003]/items[at0004]/items[at0005]/value:]
bondElement: rmobjectForValue=[data_types.text.DvText@1eff818]
Element Null ERROR Count :1
rmObjectsForValue.size :1
==============================================
bindELEMENT pathValor: 
[/data[at0001]/events[at0002]/data[at0003]/items[at0004]/items[at0006]/value/val
ue:]
No valida DvBoolean value:
bondElement: rmobjectForValue=[data_types.basic.DvBoolean@15327f4]
Element Null ERROR Count :1
rmObjectsForValue.size :1
==============================================
bindELEMENT pathValor: 
[/data[at0001]/events[at0002]/data[at0003]/items[at0004]/items[at0005]/value:]
bondElement: rmobjectForValue=[data_types.text.DvText@18d702e]
Element Null ERROR Count :1
rmObjectsForValue.size :1
==============================================
bindELEMENT pathValor: 
[/data[at0001]/events[at0002]/data[at0003]/items[at0004]/items[at0006]/value/val
ue:]
No valida DvBoolean value:
bondElement: rmobjectForValue=[data_types.basic.DvBoolean@5570e2]
Element Null ERROR Count :1
rmObjectsForValue.size :1
==============================================
bindELEMENT pathValor: 
[/data[at0001]/events[at0002]/data[at0003]/items[at0004]/items[at0005]/value:]
bondElement: rmobjectForValue=[data_types.text.DvText@1257493]
Element Null ERROR Count :1
rmObjectsForValue.size :1
bindCComplexObject rmObject tiene errores: 
org.springframework.validation.BeanPropertyBindingResult: 1 errors
Field error in object 'hce.core.datastructure.itemstructure.ItemTree' on field 
'items': rejected value [[]]; codes [ITEM_TREE.error.cardinality.hce.co
re.datastructure.itemstructure.ItemTree.items,ITEM_TREE.error.cardinality.items,
ITEM_TREE.error.cardinality.java.util.List,ITEM_TREE.error.cardinality
]; arguments []; default message [null]
Template: TEST-cluster_obligatorio_multiple esta en cache << 
templates.tom.Template@75d407 >>
Template: TEST-cluster_obligatorio_multiple esta en cache << 
templates.tom.Template@75d407 >>
Hay errors en el binder (bandera errors en true)

La reapertura es una característica que quedó de Traumagen, lo correcto y 
más genérico sería implementar enmiendas, que son correcciones a los datos 
inresados, pero sin modificar los datos ingresados. En la visualización se 
debería mostrar por defecto los datos enmendados y un medio de acceso para los 
originales.

La diferencia con la reapertura hoy implementada es que la versión original 
del registro hoy se guarda en un CDA y el usuario sigue editando sobre el 
registro original. Esto complica la implementación de la visualización del 
documento original. Además crea una dependencia con el filesystem, que puede 
causar inconsistencias entre la base relacional y el filesystem. Lo ideal 
sería que tanto la versión original, como la enmienda, sean almacenados en la 
base relacional.

Agregar texto de licencia en las clases del framework, y los nombres de los 
autores, fechas, etc.

Esto es para cubrirnos de que no nos afanen código sin permiso.

La idea es tener un par de directivas displayAsEntry y displayAsSection, la 
primera actúa sobre secciones, e indica que en lugar de mostrar el menú con 
tabs superior al registro, muestre las secciones como si fueran entradas en el 
registro. La segunda actúa sobre entradas, e indica que se muestren las 
entradas como secciones en el menú con tabs arriba del registro.

De esta forma tengo más flexibilidad en el render sin necesidad de tocar 
arquetipos, solo templates.

Hoy el framework tiene un dejo de traumagen, que para cerrar el registro, poder 
firmarlo y generar CDA debe hacer el movimiento del paciente. Entonces todos 
los registros deberán tener un movimiento de paciente para poder cerrarse, 
esto le saca generalidad.

La idea es poner un botón al final del menú para que el cierre del registro 
lo haga el médico de forma explícita, al igual que hizo la apertura. Ahí lo 
cierra y lo firma, pudiendo mostrarle los registros incompletos o avisándole 
que faltó llenar algo obligatorio.

Cada acción realizada debe ser registrada, por quién fue hecha, para quién, 
cuando, etc.

Así se permitirá trazabilidad de las tareas realizadas y auditorías 
posteriores.

También se deberían implementar funcionalidades que faciliten la 
visualización de esta información, por ejemplo gráficas de uso del sistema, 
para medir tiempos de respuesta, y detectar cuellos de botella.

En realidad Event hereda directamente de Locatable. Ver data_structures_impdf 
pag 25.

http://kenai.com/projects/openehr-app/sources/subversion/show/TRUNK/openEHRApp

http://kenai.com/projects/openehr-app/sources/40115/show/TRUNK?rev=726

Las CareEntry tienen un campo protocol, donde se puede registrar información 
de contexto. La idea es que si el arquetipo tiene protocol definido, en la GUI 
se generen esos campos. La idea sería que en alguna tab arriba o al costado 
del registro clínico, diga "protocolo", y al hacer clic, que se muestren esos 
campos para registrarlos junto a los datos de la entrada.

El protocolo también puede surgir del seguimiento de una guía de práctica 
médica.

Si se está viendo información en el sistema y pasa mucho tiempo sin ir al 
servidor, el servidor cierra la sesión.

La idea es agregar un heartbeat para que no cierre la sesión durante un tiempo 
X configurable, luego de ese tiempo, está ok que cierre la sesión.

Una mejora relacionada, es que: si cierra la sesión y te manda al login, que 
al loguearte, vuelva al lugar donde estaba.

Hoy los registros de HCE de emergencia, ambulatorio, internación, etc, son 
registrados en una Composition, según el dominio seleccionado en la 
configuración.

Un problema es que no hay forma de organizar los registros de los distintos 
dominios, entonces es necesario implementar Folders. En realidad, cada paciente 
en cada dominio tiene un folder distinto con todas las Compositions de ese 
paciente en ese dominio.

La idea sería que cuando se haga el primer registro para un paciente en un 
dominio, se cree el folder para ese paciente en ese dominio. Y que todos los 
sucesivos registros del paciente en el dominio vayan al mismo folder.

Luego, en la visualización, se pueden ver los registros organizados por 
folders (dominios).

LA idea es que todo tenga un momento de ingreso registrado, independientemente 
que se ponga un nodo fecha en un arquetipo.

De esta forma se hace más fácil consultar la base de datos por rangos de 
fechas, para cualquier entidad del RM, sin necesidad de saber si hay o no un 
nodo fecha en cada arquetipo.

Entro al dominio de trauma, voy a registrar el triage.
Ingreso la evaluación de triage y no ingreso texto.
Salvo, y me devuelve un error que debo ingresar texto, pero en el edit no me 
muestra seleccionada la evaluación de triage que hice antes de salvar.

La idea es que si un template o arquetipo, que se usó para crear un registro, 
se modifica (cambiando de versión), el registro previamente creado pueda verse 
usando la versión anterior del template y/o arquetipo.

Así se permite evolucionar siendo compatibles para atrás.

La idea es armar una estructura plana de los registros clínicos, y un proceso 
que alimente esa estructura leyendo de la estructura de datos clínicos que 
maneja el framework. La estructura resultante se podrá almacenar en la misma 
base, o ser comunicada a otro sistema para su almacenamiento. Desde ese 
sistema, tomará los datos el ETL para crear la estructura final del 
datawarehouse.

Si el DW estuviera diseñado, el paso intermedio no sería necesario, y 
generaríamos directamente la estructura como la necesita el DW (p.e. un 
esquema estrella).

En el penúltimo párrafo del documento de sintaxis de plantillas referencia 
una imagen f63 que no está en ese documento.

Ver donde está la imagen, corregir la referencia y ver si corresponde agregar 
la imagen a ese documento.

La idea es evitar clics dobles, entonces al guardar información del registro 
clínico, el botón de enviar la información debería desactivarse.

Debe permitir agregar, modificar, eliminar usuarios, setear sus perfiles y 
permisos.

Si tengo:

ITEM_SINGLE
|_ ELEMENT
   |_ DV_QUANTITY

Si no pongo valor para el DV_QUANTITY y el ELEMENT es obligatorio, me da error 
en el ITEM_SINGLE que el ELEMENT es null.

  - lo que hago hoy es si no viene el DataValue, no bindeo el ELEMENT.
  - capaz debería estar el ELEMENT y decir que su value no puede ser null ???.
  - la otra es que si el ELEMENT es obligatorio lo cree aunque tenga value null (y siempre falla la validación) y si el ELEMENT no es obligatorio y tiene value null, no creo el ELEMENT.
    - Con esta solucion lo que pasa es que si el ITEM_SINGLE es obligatorio, su ELEMENT debe ser obligatorio por restriccion del modelo. Si esto se cumple, creo que anda bien.


OBSERVATION[at0000] matches {   -- Frecuencia cardíaca
    data matches {
        HISTORY[at0001] matches {   -- Event Series
            events cardinality matches {1..*; unordered} matches {
                EVENT[at0002] occurrences matches {0..1} matches {  -- Cualquier evento
                    data matches {
                        ITEM_SINGLE[at0003] matches {   -- Unico(a)
                            item matches {
                                ELEMENT[at0004] occurrences matches {1..1} matches {    -- Frecuencia cardíaca
                                    value matches {
                                        C_DV_QUANTITY <

Aunque de la web vengan valores vacios, en el binder se llega hasta el ultimo 
nodo del arquetipo para bindear, porque recorre todo el arquetipo. 

En realidad debería parar de bindear cuando me doy cuenta que viola una 
restriccion,  si sigo para abajo ya se que va a seguir violando. Y si quiero 
crear una estructura vacía del RM para ponerle errores, puedo hacerlo solo con 
el arquetipo y sin bindear (la recorrida es la misma, pero más simple porque 
no pregunto por valores que se que no tengo).

Otra condicion de parada es si tengo una estructura opcional y no vienen 
valores para ella. No debería seguir bindeando, porque si la estructura es 
opcional, todas las subestructuras lo serán. Entonces estoy recorriendo un 
arquetipo sabiendo que no tengo datos, pero que no está mal que no los tenga 
(no viola ninguna restricción, entonces no genera error que no esté).

Esta segunda condición de para es similar a algo que hacía antes, que era 
preguntar desde el padre, si los hijos eran opcionales, y si eran opcionales, y 
no viene ningún path-valor para bindear, no sigo bindeando.

Especificar una sintaxis que permita definir informes en base a la información 
registrada para diversos conceptos clínicos. Esto podría ser una extensión a 
los templates, con posibilidad de definir agregación de datos e indicadores 
calculados.

Luego crear un editor de estas especificaciones para que sea simple definir 
este tipo de reportes.

En lugar de generar la GUI cada vez que se cambia de tab, porque una sección 
tiene varias entradas, en el acceso a la sección, cuando se muestra la primer 
entrada, se podrían cargar las demás entradas del lado del cliente, y estas 
se muestran con JS cuando se hace clic en una tab. Esto ahorra ir al servidor 
cada vez y regenerar toda la pagina.

Este ejemplo de tabs puede servir: http://dojotoolkit.org/widgets

Este esquema podría servir no solo para las entradas de una sección, podría 
servir para cargar del lado del cliente todas las vistas de todas las secciones 
y todas sus entradas.

Para que esto funcione, se debería guardar usando ajax, para no recargar la 
página.

Sobre la plataforma linux, al crear un CDA la aplicacion se cae.

Hay un problema en la path a la que se quiere redirigir.

La idea es que un rol puede realizar registros en varios dominios (emergencia, 
trauma, internacion, ambulatorio, etc).

Entonces cuando un usuario ingresa al sistema, el sistema le presenta un 
escritorio donde puede elegir a qué dominio desea ingresar, luego que ingresa 
al dominio, registra con el proceso asistencial de ese dominio (determinado por 
un conjunto de templates).

A priori no se tendrán restricciones sobre la selección del dominio, luego, 
se deberá exigir que no se puede cambiar de dominio si no se cierran los 
registros abiertos del dominio actual (en la realidad no puedo cambiar de 
dominio y seguir registrando en la misma sesión). La otra es hacerlo loguearse 
de nuevo, para seleccionar otro dominio, eso sería innecesario.

Para realizar capacitación, esta restricción no es necesaria.

Los dominios a los que puede acceder un usuario están determinados en la 
gestión de permisos de cada rol y persona.

Si de Pathable solo hereda Locatable, implementarlas como una sola clase.

Ver pag 13 common_im.

Si se intenta llenar un registro como Evaluación Primaria > Vía Aérea, el 
Element de si tiene o no alteraciones es obligatorio, en ese registro, si no se 
llena valor para ese Element, al validar tira un error. Ese Element está 
dentro de un ItemTree.

Luego, en el registro de Evaluación Primaria > Estado Circulatorio, el Element 
de la Frecuencia Cardíaca también es obligatorio, y al no llenarse no 
devuelve ningún error de validación. En este caso el Element está dentro de 
un ItemSingle.

Debe haber algún bug en el Binder que no valida el caso de elementos 
obligatorios dentro de ItemSingle.

Hoy prototype se usa solo para clonar los nodos múltiples. Eso mismo se 
podría hacer con jQuery, y con jQuery y sus plugins se puede agregar mucha 
funcionalidad de GUI, como el submit de formularios por javascript mientras el 
usuario está escbribiendo (salvar parcialmente los datos, o validar los datos 
ingresados).

En el resumen de registro de trauma se muestra el triage, RTS y algunas 
variables más, pero esto es válido solo para trauma.

La idea sería poder definir qué es lo que se muestra en el resumen del 
registro (cuadro superior dentro del registro clínico), dentro de algún tipo 
de configuración, que podría ser el Config.grovy, un template, o una 
configuración aparte especializada para el resumen.

El objetivo es que los valores que ahí se muestran, puedan ser expresados de 
forma declarativa (p.e. usando nombres para las variables y que el framework 
interprete esos nombres, procese lo que sea necesario y muestre el resultado). 
Otra opción sería que se cree un pequeño script groovy o template gsp, y que 
se use uno u otro dependiendo del dominio. Esta es la solución más directa y 
fácil de implementar.

Implementar la validación de la estructura interna de los templates, de modo 
de que si una path no existe, cuando se carga un template por primera vez, se 
indique el error. Para verificar las paths, se debería cargar el arquetipo al 
que se hace referencia (agregando una dependencia que ahora no hay entre 
templateManager y archetypeManager, no creo que sea tan complicado y no joroba 
a la arquitectura).

También para cuando se tiene un includeAll=true y se tienen fields declarados 
en un archetypeRef (si va uno, no debería ir el otro).

La notificación podría ser en consola, o podría salir por el programa cuando 
se está en modo DEV. La idea es que si un template no pasa la validación, que 
no sea cargado.

Hay un problema en generateShow.gsp y es que se llama al template Locatable 
para mostrar el contenido de la estructura del RM, pero habría que ver en el 
template si los fields incluidos muestran desde la raíz de la estructura o 
desde algún nodo intermedio.

Lo que hay ahora funciona Ok si arranca de la raíz y en el template se tiene 
includeAll=true para todos los archRefs, pero si un archRef tiene un field con 
path distinta a "/", en el generateTemplate el formulario genera nodos a partir 
de la path de ese field, p.e. "/description[at0001]", pero al ingresar y 
guardar datos, el generateShow, para ese registro genera la GUI a partir de 
"/", mostrando cosas que no aparecían en el ingreso de información (como la 
label de un nodo OBSERVATION).

Con esto quedaría consistente la generación del create/edit y del show.

Lo que hay que ver en generateShow:

<!-- FIXME: habria que arrancar del nodo que diga el template (p.e. esto es 
correcto si arranca de la raiz pero no si tiene un field con path distinta a / 
-->

<!-- RM -->
<g:render template="../guiGen/showTemplates/Locatable"
          model="[rmNode: index[archRef.id],
          archetype: archRef.getReferencedArchetype()]" />