Interacción y personalización Repositorio FHIR

Siempre que se trabaja con el repositorio FHIR,  se tiene que interactuar con lógica de negocio propia de la institución donde se instala.

Surgió una regla bastante simple, para efectos de demostración, que consiste en validar la existencia de un paciente en el repositorio, aún si es una petición que contiene un Patient Resource enviado vía método POST, lo cuál por definición del estándar FHIR, corresponde a un Create Patient. Las actualizaciones de cualquier recurso FHIR se realizan a través del método HTTP UPDATE, sin embargo podría suceder que por error se nos envíe una petición POST y se creen numerosas instancias del mismo paciente.

La unificación de registros de pacientes, es algo que normalmente es resuelto por un Maestro de pacientes (MPI/EMPI), sin embargo, en casos de uso acotado, donde se pueda confiar en un único identificador nacional de paciente, pues se puede considerar que el repositorio realice la validación de la existencia del paciente a través de una consulta previa.

Entonces para nuestra demo usamos una producción que interactúa con un servidor FHIR, instalado con configuración default, con un Business Process (BP) orquestando la validación:

Nuestro BP evalúa primeramente el tipo de mensaje con la finalidad de evaluar si debía aplicarle la lógica de validación o directamente enviarlo al repositorio FHIR:

La regla de negocio es bastante sencilla, dado que estaba centrada solo en identificar el mensaje del recurso FHIR del paciente. Pasamos el request de tipo HS.FHIRServer.Interop.Request al contexto del BP, para que fuera visible desde la regla:

Incorporamos un flag en el BP que controla si se debe aplicar la validación, de lo contrario se envía el mensaje al servidor FHIR:

Class MEDERI.BP.MPI.Process Extends Ens.BusinessProcessBPL
{

Property ValidarPacientesExistentesEnCreacion As %Boolean;

Parameter SETTINGS = "ValidarPacientesExistentesEnCreacion:Basic";

<if name='Valida en creación ' condition='process.ValidarPacientesExistentesEnCreacion &gt; 0' xpos='470' ypos='600' xend='470' yend='2000' >
<true>

Este flag queda disponible a través de la UI de la producción

La serie de actividades de la validación, las vemos en la siguiente secuencia:

El BP llama a un método personalizado para obtener los identificadores desde el mensaje FHIR. Preferimos usar un método de clase, dado que como resultados necesitamos una cadena de texto concatenada para pasarla como parámetro de búsqueda de FHIR

<assign name="Obtener Identificadores" property="context.identificadores" value="##class(MEDERI.Facade.Patient).GetListaIdentificadores(request,.status)" action="set"/>

Cabe recordar que el Business Service (BS) FHIR core, genera un objeto del tipo HS.FHIRServer.Interop.Request, el cual nosotros tomamos como parámetro de nuestro BP. La gran parte de las propiedades del objeto Request de tipo HS.FHIRServer.Interop.Request para el BO FHIR, las obtenemos desde la Request original, simplemente asignando todos las propiedades que tienen valor, a través de una DTL. El cambio importante es el método HTTP, representado por la propiedad RequestMethod, al cuál le asignamos la cadena "GET"

Y luego le asignamos la cadena de texto de los identificadores a la propiedad QueryString: 

<assign name="Asignar identif busqueda" property="context.patientSearchRequest.Request.QueryString" value="context.identificadores" action="set"/>

Posteriormente enviamos este nuevo Request al repositorio FHIR. Este nos responderá con el resultado de la búsqueda, a través de un recurso del tipo Bundle, del cuál nos interesa la propiedad "total", el cuál rescatamos a través de un método de clase personalizado:

De encontrar pacientes que coincidan con los identificadores, entonces enviamos un mensaje de error personalizado. De no encontrarlo, le dejamos la responsabilidad al repositorio FHIR:

Este mensaje de error personalizado se modela como un objeto de tipo HS.FHIRServer.Interop.Response. Si llamamos vía Postman, lo veremos de la siguiente forma:

Dado que el mensaje incluye información de los identificadores, entonces usamos un método de clase para crear la descripción del mensaje.

Pronto les compartiré el proyecto para que puedan visualizar el código fuente que generamos.

Espero esta demostración les pueda ayudar.