Review:Cases in which medical expenditures and/or reserves each reach $3,000.00Anticipated or actual inpatient or outpatient surgery of any typeAnticipated or actual hospitalizationAll back injuriesAll repetitive motion/cumulative trauma disorder/injuriesAll claims with prior injury history to same or related body part, and/or current open claimRestricted duty over 2 weeksAny injury with anticipated/actual off work days greater than five days.All shoulder injuries
This is a nice case study to examine how to analyze a situation and model a decision service. However, I run into far more complex condition sets when determining something like claims for home health agencies and skilled nursing facilities, to name a few. Although I understand how the simple model can be expanded, I still struggle with the vastness of data that my Medicaid/Medicare reality often deals with.
You are quite correct. The attached example has a very convenient flat vocabulary. Real world problems are rarely that simple.
It's worth noting that there are two orthogonal dimensions to complexity:
1. There can be a lot more rules (using a lot more attributes and a lot more combinations of conditions).
2. There can be a lot more business objects (with complex relationships such as one to one or one to many between them).
The first is typically just a matter of scale - you just end up with more rule sheets each of which has more rule columns and more condition entries. Fortunately the Completeness and Consistency checking tools in Corticon help in getting this right. Grouping rules into rule sheets and rule sheets into sub flows provides one way to manage things as they grow and compartmentalize the logic.
The second (more business objects and relationships) is where it really gets challenging.
Unfortunately I don't have a magic formula for making that part easier (although Progress and our partner Nimble Consulting do offer professional services to assist with this task). However, from past experience (sometimes painful), I can say that it is definitely worth spending a significant amount of time up front to develop the data model that the rules will use.
The SCOPE section of the Corticon rule sheet does provide a degree of "magic" in helping you traverse complex data
hierarchies without writing any code but its still a challenging task.
Even before writing any rules I find it very helpful to create some test data based on the vocabulary I have created. Often that step alone will suggest better ways to represent the data.
You may be lucky enough (or unlucky enough) to have a data model provided to you. You should ask whether that data model is the right one for use by rule authors. Typically a data model is based on existing physical data base tables (and is often normalized for improving machine efficiency rather than human efficiency) and is NOT necessarily the best one for rule authors.
Ideally the data model for rule authoring should be a logical model that reflects how the business thinks about its data. In general one should avoid writing rules using the physical data structure (since the physical representation may change) but rather use the logical data structure (which is likely to change less).
Of course you may still be faced with working with the physical data structure (in tables) but one technique for dealing with this is to write initial rule sheets that convert the physical data into a logical structure that is easier for the rule authors to work with. And if necessary another rule sheet at the end to convert the logical model back to the physical model. This technique can be particularly helpful when dealing with older databases such as Open Edge. It also provides a degree of isolation from the physical world - it should be possible to take the logical rules and apply them to a different database by replacing the rule sheets that map from the physical world to the logical world.
Typically this part would be done by someone on the IT side who has a good understanding of the physical data model. It may be that you would use the Corticon Enterprise Data Connector (EDC) to access the physical data directly from within Corticon (for increased flexibility and convenience). Or you might prefer to create a Service Call Out that enables you to isolate the data access routines in java or .NET code (for tighter control). The client application that calls Corticon could also handle the access to existing physical databases.
There are a variety of other tools on the market that may help in dealing with this.
For example RuleXpress and DecisionsFirst.
Some of the other examples in the Documents section have more complex vocabularies.