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: ![](/sites/default/files/inline/images/images/image(3037).png) 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: ![](/sites/default/files/inline/images/images/image(3038).png) 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: ![](/sites/default/files/inline/images/images/image(3039).png) 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 > 0' xpos='470' ypos='600' xend='470' yend='2000' > <true> ![](/sites/default/files/inline/images/images/image(3040).png) Este flag queda disponible a través de la UI de la producción ![](/sites/default/files/inline/images/images/image(3042).png) La serie de actividades de la validación, las vemos en la siguiente secuencia: ![](/sites/default/files/inline/images/images/image(3045).png) 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_" ![](/sites/default/files/inline/images/images/image(3046).png) 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: ![](/sites/default/files/inline/images/images/image(3050).png) 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: ![](/sites/default/files/inline/images/images/image(3047).png) 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: ![](/sites/default/files/inline/images/images/image(3048).png) 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.