Pregunta
· 21 oct, 2022

FHIR Intellisense en ObjectScript

Buenos días, tardes, noches,... wink

Una pequeña reflexión/pregunta para hoy... es una realidad que las nuevas versiones de IRIS for Health son cada vez más potentes en cuanto a capacidades FHIR. Permiten consumir recursos FHIR con extrema facilidad, podemos crear conexiones con end-points de servidores FHIR externos muy facilmente y hacer que IRIS actúe de passthrough o que consuma esos recursos... o, más aún, podemos definir y poner en funcionamiento un repositorio FHIR, literalmente, en menos de 5 minutos.

Sin embargo, hay una cosa que echo en falta en proyectos de tipo FHIR Façade, cuando tenemos que implementar una capa FHIR sobre un sistema que "no habla" FHIR. Se trata de la posiblidad de tener ayuda en nuestro IDE (Studio o VS Code) a la hora de codificar la lógica que crearía el o los objetos dinámicos (%DynamicObject) que representan los recursos FHIR que queremos definir...

Creo que sería de mucha ayuda disponer de estructuras/objetos que representasen los recursos de la versión FHIR con la que estemos trabajando, de modo que el intellisense de nuestro Studio o VS Code nos pudiera ofrecer ayuda en cuando a propiedades, objetos referenciados, etc,... y, no sólo eso, sino que también pudieramos utilizar esos objetos como base a la hora de definir nuestras transformaciones en el editor DTL, para crear recursos/objetos FHIR a partir de otros datos persistentes.

No sé si es algo que sólo yo echo en falta o es más comun, por eso quería lanzar la pregunta a la comunidad. ¿Os habéis encontrado con esta situación? ¿Pensáis que es una funcionalidad interesante? ¿Tenéis algún workaround que queráis compartir?

Lo planteé en su día en el Portal de Ideas/Sugerencias que InterSystems pone a disposición de la comunidad. Aquí está la entrada por si queréis votar por ella, o aportar ideas/workarounds, etc...

Bueno, pues ahí queda la reflexión/pregunta.

¡¡Happy Coding!!

Product version: IRIS 2022.1
Comentarios (3)2
Inicie sesión o regístrese para continuar

Casi, casi,... se acerca mucho pero esas clases representan los recursos tal cual de las distintas releases... está muy bien, pero no podríamos usarlas cuando estemos utilizando un profile específico que sea distinto de la versión estándar. Por ejemplo, si tuvieramos un profile para España que modificase el recurso paciente para añadir un segundo apellido, ¿cómo lo haríamos? Quizá valdría con tener una utilidad que genere automáticamente un paquete, similar al *.vR4.Model.Resource.*, para ese profile específico... Es una idea para una solución en OpenExchange... a ver si alguien coge el testigo! 😉