Desafío
Desde DECISION MANAGEMENT COMMUNITY proponen cada ciertos meses unos retos sobre Decision Management que cuelgan en su web, en los que cualquiera puede participar y mandar su solución utilizando cualquier sistema de gestión de decisiones y reglas de negocio.
El reto para febrero de 2021, Benchmark “Medical Services”, consiste en implementar un servicio de decisión que sea capaz de asignar la cobertura de un servicio médico contratado. En dedide4AI, se han encargado nuestros compañeros: Azahara Talavera, Thomas Follon, Lorena Roa y Facundo López. Veamos más sobre el reto y la solución propuesta.
Nos dan el formato JSON que debe tener la entrada y la salida:
También nos dan las 16.369 reglas a implementar en el servicio y que asignan la cobertura en función del servicio médico contratado.
El objetivo de este reto es comparar el rendimiento de las diferentes implementaciones y plataformas en las que se desarrolle el servicio.
Solución
Para dar respuesta a este challenge, hemos implementado un servicio de decisión utilizando el Sistema de Gestión de Reglas de Negocio (BRMS) de IBM, ODM Operational Decision Manager V8.10.0.
En el servicio de decisión implementado, se han definido todas las reglas proporcionadas por el challenge, organizándolas de manera que al usuario de negocio le sea fácil identificar y entender la estructura del servicio, lo que le permitirá modificar las reglas de negocio de forma ágil.
A continuación, una breve descripción de nuestra solución y los artefactos de negocio de los que se compone nuestro servicio de decisión.
1. Operación, artefactos y flujo
Primero, creamos una operación en la que definiremos los parámetros de entrada y salida. En este caso todos los parámetros actúan como parámetros de entrada-salida, ya que se devolverán los mismos campos.
En segundo lugar, definimos el flujo del servicio:
El flujo se compone de los nodos de entrada y salida, y dos ruleTask. En cada uno de los RuleTask hemos creado las reglas de negocio conforme a la funcionalidad de cada agrupación.
2. RuleTasks
- El primer ruleTask (‘Validate Not Informed’) se encarga de verificar que toda la información que se necesita para determinar el servicio médico está informada.
- El segundo ruleTask (‘Classify Service’) se encarga de ejecutar las reglas elegibles en función de las condiciones de entrada, asignando los valores de salida según corresponda.
3. ‘Validate Not Informed’
Este ruleTask se compone de una carpeta (Validate Not Informed) en la que hay dos reglas de comprobación de datos en su interior:
- Group Size – Comprueba que el ‘groupSize’ no sea nulo, y si lo es, asigna a la variable ‘group size’ el valor Uninformed.
- Is covered – Comprueba que el ‘isCovered’ no sea nulo, y si lo es se asigna a la variable ‘is covered’ el valor Uninformed.
4. ‘Classify Service’
En este ruleTask, las reglas a su vez se agrupan en dos carpetas diferentes, Empty Place y Service Type, de la siguiente forma:
La primera carpeta Empty Place solo hay una tabla que se encarga de comprobar aquellos casos que el placeOfService no esté informado.
En esta decisión se puede ver como la entrada determinar la asignación de servicio médico.
La segunda carpeta cubre todos los demás casos y están divididos de la siguiente manera:
Existen dos tablas de decisión por cada ServiceType, una cuando In Network toma valor ‘Y’, y otra cuando In Network toma el valor ‘N’. Estas tablas están organizadas según su PlaceOfService.
Cada tabla tiene sus precondiciones:
- Tabla ‘In Network’ – Esta tabla es elegible si se cumplen las siguientes precondiciones:
- ‘place of service’ toma el valor Inpatient
- ‘service type’ toma el valor acunpuncture
- ‘in network’ toma el valor Y.
- Tabla ‘NOT In Network’ – Esta tabla es elegible si se cumplen las siguientes precondiciones:
- ‘place of service’ toma el valor ‘Inpatient’
- ‘service type’ toma el valor ‘acunpuncture’
- ‘in network’ toma el valor ‘N’.
El formato de todas las tablas es el mismo. Hay que tener en cuenta que cada fila de la tabla, corresponde a una de las reglas de decisión proporcionadas por el challenge.
Se comprueban el resto de condiciones, y en caso de que se cumplan, se le asigna a cada una de las variables de salida el valor correspondiente en cada caso.
El servicio de decisión está expuesto como un servicio HTDS (REST), de forma que puede dar respuesta a llamadas en formato json.
Resultado y conclusión
Respecto al objetivo del reto (el rendimiento de la solución aportada) la batería de pruebas dadas que consta de 10 casos, se ha ejecutado en 214 ms.
Hemos elegido ODM Operational Decision Manager de IBM para dar respuesta al challenge porque es una herramienta ágil que permite gestionar las decisiones y cambiar reglas de negocio de una manera clara y rápida. Además, es accesible y legible para usuarios de negocio, que pueden identificar y modelar las decisiones, crear servicios de decisión automatizando las tomas de decisiones, y controlar en todo momento el proceso para mejorar los servicios o realizar cambios.
Es una herramienta que aporta agilidad, accesibilidad, legibilidad, ahorro de tiempo, y decisiones rápidas, claras, accionables y reutilizables.
¿Interesado en saber más sobre cómo aplicamos ODM en decide4AI?
Si quieres saber más sobre decide4AI y mantenerte al tanto de futuros webinar o eventos, síguenos en las redes sociales (Linkedin, Twitter, Youtube).