Hola Mi nombre es Andrey, trabajo en una empresa que crea soluciones de TI en el campo de la medicina. Como lenguaje principal de desarrollo, utilizamos Clojure, así como (según el proyecto / módulo) Python, Javascript, Go, C, C #, Rust, Objective-C, etc.
Un lugar importante en nuestra pila tecnológica está ocupado por el estándar internacional
FHIR (Fast Healthcare Interoperability Resources), que define el formato para almacenar / intercambiar / proporcionar información médica en forma electrónica e incluye la especificación
RESTful API de interacción cliente-servidor.
Hace algún tiempo, comencé un proyecto favorito de una aplicación que visualiza el contenido de los recursos de un servidor FHIR arbitrario y le permite realizar operaciones CRUD básicas. El KDPV muestra una captura de pantalla de la página de edición para un elemento de recurso del tipo Paciente.
Debajo del gato hay una breve descripción y un enlace a una demostración en línea: será posible tocar un servidor FHIR en vivo real, presionar botones, ver / crear / editar varios recursos e incluso intentar invocar el mismo efecto habra. )
Algunas palabras sobre FHIR
No volveré a escribir la descripción de la norma aquí, aquellos que lo deseen pueden aprender todos los detalles del enlace anterior, leer otros materiales sobre diversos recursos, así como hacer preguntas y unirse a la discusión en el
chat de FHIR . Solo daré una idea general: el concepto central es un recurso, los recursos están divididos por tipos y grupos, cada tipo tiene su propia estructura de campo, cuyos valores pueden ser tipos primitivos o compuestos y enlaces a otros recursos. Los campos pueden ser obligatorios u opcionales, contener un valor o una colección de valores. Por ejemplo, el recurso
Paciente tiene campos de un tipo primitivo: fecha de nacimiento / género / ..., tipo compuesto: nombre / dirección / ...., enlaces a la organización y la lista de médicos asistentes, etc.
Para cada recurso, el historial de sus cambios se almacena como una lista de estados con las fechas de su relevancia y el número de versión del objeto. La API RESTful le permite solicitar metadatos sobre la composición y estructura de los recursos admitidos por este servidor FHIR, una lista de elementos de recursos de cualquier tipo con amplias capacidades de filtrado de acuerdo con los valores de parámetros individuales, inclusión de recursos dependientes, restringir la salida de los resultados a los valores de los campos enumerados, ordenar el resultado de la consulta por criterios complejos y etc. También hay métodos para admitir CRUD a nivel de un elemento de recurso: creación / actualización con validación de estructura y la presencia de campos obligatorios, eliminando un elemento. Existen métodos de API para ver el historial de cambios tanto a nivel de elemento como a nivel de tipo de recurso.
En una aplicación típica, el uso de esta API genérica se abstrae mediante una gruesa capa de lógica empresarial para un cliente en particular. Por ejemplo, al designar la visita de un paciente a un médico, se les solicita información sobre el número de sus seguros médicos y sus períodos de validez, historial de visitas anteriores, información sobre el saldo de acuerdos entre el paciente y la clínica, etc., datos sobre el horario del médico seleccionado y la disponibilidad de horas de admisión, etc. .p. Y todo esto se presenta convenientemente en la pantalla del lugar de trabajo del empleado que realiza la grabación. O bien, el programador automático de tareas inicia periódicamente un proceso de acuerdo con un cronograma dado, solicitando una lista de las próximas visitas y enviando automáticamente SMS a los pacientes con el texto de recordatorios o notificaciones de acuerdo con plantillas predefinidas.
Pero se me ocurrió la idea de hacer una visualización universal de los contenidos de los recursos del servidor FHIR, y entonces un proyecto llamado ...
Cara fhir
La aplicación le permite conectarse a cualquier servidor FHIR y ver el contenido de los recursos y CRUD básico. Una de las dificultades de un enfoque tan universal es que diferentes servidores pueden tener diferentes versiones del estándar FHIR, implementarlo en su totalidad, tener desviaciones en la lista, composición y estructura de recursos y API, y también tienen una funcionalidad adicional que no está incluida en la especificación . Pero si este servidor le permite solicitar metadatos sobre la composición y estructura de los recursos admitidos, puede agregar su compatibilidad en este proyecto.
La interfaz del proyecto es intuitiva. La dirección del servidor se selecciona a través del parámetro de la barra de direcciones, pero en la versión demo actual,
hapi.fhir.org se selecciona de manera
predeterminada . Desde la página de inicio, se descarga la composición y estructura de los recursos, y se propone seleccionar un tipo específico de recurso para ver su contenido. Al elegir el tipo de recurso, se realiza una solicitud para un número limitado de sus elementos, que se muestran en una tabla con columnas: identificador, representación condicional del usuario (si es posible) y tamaño en caracteres de serialización de cadenas. Una búsqueda de texto completo en el contenido del recurso funciona. Cuando hace clic en una fila de la tabla o en el botón para crear un nuevo elemento, se produce una redirección a la página del contenido del elemento de recurso.
En la parte superior de la página del elemento hay botones para la convolución / despliegue completo del contenido jerárquico y un botón para cambiar el estilo de presentación de los detalles. El contenido del artículo está representado por una lista de detalles. Cada atributo tiene un nombre, tipo, breve descripción y significado. Un círculo lleno de negro a la izquierda del atributo significa que este atributo está presente en el recurso (incluso si su valor no está seleccionado; en este caso, el atributo tiene este atributo, pero tiene un valor vacío), un círculo vacío indica la ausencia de este atributo en el elemento, pero la lista detalles de la estructura de este tipo de recurso. Cualquier atributo se puede agregar / eliminar del elemento haciendo clic en el icono del círculo a la izquierda del nombre. Los detalles que no figuran en la estructura del tipo de recurso, pero están disponibles en el elemento, se resaltan en púrpura.
Los valores de los tipos primitivos están representados por los widgets tipados correspondientes: fecha, hora, número, cadena, etc. El icono a la derecha de los detalles de la cadena cambia el modo de entrada / edición de texto, con o sin avance de línea. Al editar, el widget cambia de tamaño automáticamente según su contenido. Al comenzar a completar el formulario, todos los campos de texto de más de 50 caracteres están representados por widgets textArea con avances de línea. Los widgets de enlace están representados por el tipo de recurso de enlace y el valor, al elegir un valor, funciona una búsqueda de texto completo en el contenido del recurso de enlace.
Los detalles de los tipos compuestos se pueden contraer para resaltar el número de detalles subordinados posibles y completados o desplegarse con una demostración de los contenidos. Cuando hace clic en el nombre / tipo / descripción del requisito, se activa una convolución / despliegue completo y profundo del contenido; cuando hace clic en el resaltado, el número de campos es el despliegue del siguiente nivel de detalles. Los atributos de la colección (con un número arbitrario de valores) tienen un icono
+ a la derecha de la descripción del atributo, para agregar nuevos valores a la colección. La convolución / despliegue de un elemento de colección (si es, a su vez, un valor de un tipo compuesto) se lleva a cabo haciendo clic en la parte más a la derecha del marco que limita el elemento de colección. Cuando hace clic en la cruz en la esquina superior derecha del marco, el elemento de colección se elimina.
Esta interfaz le permite editar el contenido de cualquier recurso. En la parte inferior de la página hay un botón para guardar el recurso en el estado editado. Cuando se escribe un recurso, el servidor FHIR valida su contenido y, si hay errores, no registra el recurso, pero devuelve una lista de errores de validación. En este caso, el texto de estos errores se muestra en rojo debajo del botón Guardar. La estructura del objeto de errores de validación está determinada por la implementación del servidor; por lo tanto, se eligió una variante de su representación textual universal. Si no hay errores, el elemento de recurso se registra y se redirige a la página de lista de elementos.
Y finalmente, los enlaces prometidos:
Demo en línea del proyectoGithub del proyecto : el gato no es un animal de peluche de exhibición, sino un trabajador vivo, por lo que hay áreas comentadas, andamios y otros elementos necesarios para el trabajo de construcción e instalación, use cascos)