Every few months, DECISION MANAGEMENT COMMUNITY proposes challenges on Decision Management that are posted on their website, in which anyone can participate and submit their solution using any decision management and business rules system.
The challenge for February 2021, Benchmark “Medical Services”, consists of implementing a decision service capable of assigning the coverage of a contracted medical service. At dedide4AI, our colleagues Azahara Talavera, Thomas Follon, Lorena Roa and Facundo López have been in charge. Let’s learn more about the challenge and the proposed solution.
We are given the JSON format that the input and output must have:
They also give us the 16,369 rules to implement in the service and which assign coverage based on the contracted medical service.
The objective of this challenge is to compare the performance of the different implementations and platforms on which the service is developed.
To respond to this challenge, we have implemented a decision service using IBM’s Business Rules Management System (BRMS), ODM Operational Decision Manager V8.10.0.
In the implemented decision service, we have defined all the rules provided by the challenge, organizing them in a way that makes it easy for the business user to identify and understand the structure of the service, which will allow him to modify the business rules in an agile way.
The following is a brief description of our solution and the business artifacts of which our decision service is composed.
1. Operation, artifacts and flow
First, we create an operation in which we define the input and output parameters. In this case all parameters act as input-output parameters, since the same fields will be returned.
Second, we define the flow of the service:
The flow is composed of input and output nodes, and two ruleTasks. In each of the RuleTask we have created the business rules according to the functionality of each group.
- The first ruleTask (‘Validate Not Informed’) is responsible for verifying that all the information needed to determine the medical service is informed.
- The second ruleTask (‘Classify Service’) is responsible for executing the eligible rules based on the input conditions, assigning output values accordingly.
3. ‘Validate Not Informed’
This ruleTask consists of a folder (Validate Not Informed) in which there are two data checking rules inside:
- Group Size – Check that the ‘groupSize’ is not void, and if it is it will be assigned to ‘group size’ the value Uninformed.
- Is covered – Check that the ‘isCovered’ is not void, and if it is it will be assigned to ‘is covered’ the value Uninformed.
4. ‘Classify Service’
In this ruleTask, the rules are grouped into two different folders, Empty Place and Service Type, as follows:
In the first folder Empty Place there is a table that is responsible for checking those cases that the placeOfService is not informed.
In this decision, you can see how the entry determine the medical service assignment.
The second folder covers all other cases and are divided as follows:
There are two decision tables for each ServiceType, one when In Network takes value ‘Y’, and another when In Network takes value ‘N’. These tables are organized according to their PlaceOfService.
Each table has its preconditions:
- Table ‘In Network’ – This table is eligible if the following preconditions are met:
- ‘place of service’ takes the value Inpatient
- ‘service type’ takes the value acunpuncture
- ‘in network’ takes the value Y.
- Table ‘NOT In Network’ – This table is eligible if the following preconditions are met:
- ‘place of service’ takes the value ‘Inpatient’
- ‘service type’ takes the value ‘acunpuncture’
- ‘in network’ takes the value ‘N’.
The format of all tables is the same. Note that each row of the table corresponds to one of the decision rules provided by the challenge.
The rest of the conditions are checked, and if they are met, each of the output variables is assigned the corresponding value in each case.
The decision service is exposed as an HTDS (REST) service, so that it can respond to calls in json format.
Result and conclusion
Regarding the objective of the challenge (performance) the given test battery consisting of 10 cases has been executed in 214 ms.
We have chosen IBM’s Operational Decision Manager to respond to the challenge because it is an agile tool that allows us to manage decisions and change business rules in a clear and fast way. In addition, it is accessible and readable for business users, who can identify and model decisions, create decision services by automating decision making, and control the process at all times to improve services or make changes.
It is a tool that provides agility, accessibility, readability, time savings, and fast, clear, actionable and reusable decisions.
Interested in learning more about how we implement ODM at decide4AI?