[AccessD] State machines

Having created a state machine for the claim call center 
software, I wanted a system where I could easily find (for 
example) "what was the date of the event that caused the 
current state" or "what event actually caused the current 
state and what notes were associated with it", that kind of 
thing.

I added fields to the event to hold a pointer to:

1) The previous event: the event immediately previous to 
this event.
2) The current status event: what event caused the current 
status.
3) The previous status event: what event caused the PREVIOUS 
status.

What I failed to do is the final piece of

4) Next event: What is the next event in the chain.

Anyone familiar with linked lists know that there are single 
linked lists and doubly linked lists.  In my case I created 
a link backwards to the previous event but no link forward 
to the next event.

Anyway I designed a system to load all the events for one 
specific claim into class instances (clsClaimEvent), then 
store those instances in a collection in a supervisor 
(clsClaimEvents).  My code allows iterating through the 
events updating the pointers to the previous events, as well 
as getting the specific event records for previous, current 
status and previous status, as well as a generic "give me 
this event record" (by EVPKID).

I use this in the claim form.  As the claim form opens for a 
given claim I open clsClaimEvents which loads all instances 
of clsClaimEvent and stores them keyed by EVPKID.

As an example of where I use this stuff, we need to enter 
benefit records, which are basically "we are going to make a 
payment now" records.  Claim records have fields which 
define the date the claim was filed, the date of disability, 
the paid through date etc.  There are "can't file a claim 
for X days after you bought the policy" kind of dates.

Now the benefit payment (this check) will be for this 
starting date through this ending date.  In some cases I 
need to know things that are in event records, for example 
when a claim was closed (the person returns to work)

In order to help the user enter these payments and minimize 
errors I have to check information from the events and 
compare those "effective dates" against the dates being paid.

This Event class system allows me to easily find the actual 
record that caused status changes so I can look for claim 
closed events, reopened events and so forth.  The dates in 
these events are then compared against the dates to being 
entered to warn the user that they may be entering a payment 
for dates which the data does not support paying.

The events themselves contain the status information to 
control the state machine, but they are also the history of 
the claim and this class system I am discussing now makes 
programmatic access to that information possible.

Just as a matter of interest, there are almost 500,000 
events in the event table.  Many claims have more than 100 
events, one claim has 250 events.

John W. Colby
www.ColbyConsulting.com


jwcolby wrote:
> How many of you know what a state machine is?
> 
> http://en.wikipedia.org/wiki/Finite_state_machine
> 
> More generically a state machine is a structure (hardware or 
> software) that stores the current "state" of something and 
> uses stimuli to cause changes from the current state to some 
> other state.  State machines prevent and allow state changes 
> from a specific state to another specific state.
> 
> IOW from this state you can only move to "these other 
> states" and which state you actually move to will be 
> determined by something that occurred.
> 
> I wrote a state machine for my disability call center software.
> 
> During the processing of claims, EVENTS happen.  Events can 
> be (pretty much) anything that the client wants to call an 
> EVENT, IOW it has to be programmable by the client.  Some 
> actual EVENTS from the event table:
> 
> New Claim Notice
> Approve
> Pend
> Terminate
> Deny
> Re-Open
> Suspend
> Delete This Event
> Receive
> Appeal
> Uphold Denial
> Uphold Termination
> Transfer In
> Transfer Out
> Not Received
> 
> There are MANY MANY more.
> 
> Events MAY or may not cause STATUSES.  Some actual statuses 
> from the STATUS table:
> 
> CS_Status
> None
> First Notice
> Open
> Pending
> Terminated
> Denied
> Re-Opened
> Suspended
> Received
> Appeal
> Upheld Denial
> Upheld Termination
> Transfer In
> Transferred Out
> Determined at IDE
> Archived
> Not Received
> 
> Now, obviously EVENTS and STATUSES are NOT the same thing. 
> Events MAY CAUSE a status change, however there are RULES 
> about what STATUS can be "moved to" from the current status. 
>   For example you cannot go to the CLOSED status unless the 
> claim is OPEN.  You cannot RE-OPEN a claim that is ALREADY 
> in the OPEN state.  APPEAL can move to UPHELD DENIAL, UPHELD 
> TERMINATION or OPEN, and so forth.
> 
> So you have to have a transition table that maps the current 
> status to "POSSIBLE" status, IOW "where can you go from 
> here".  You also have a stimulus table that maps "this event 
> can cause this status (or causes NO status change)".  An 
> OPEN event causes an OPEN status, but a "DOCUMENT RECEIVED" 
> or a "LETTER SENT" event does not cause a status change.
> 
> And finally you have a table that says "this event can 
> happen when in this state".
> 
> Then of course you have a class system that enforces the 
> rules.  It loads all of the tables into class instances 
> which are then stored in collections.
> 
> The tables are "the rules" for the state machine and are 
> fully programmable by the client.  The user is presented a 
> list of "possible events" in a combo box.  Basically the 
> current status is discovered and used to filter the list of 
> events to those that can occur in that state.  The user can 
> therefore only select an event if the system says that it 
> can occur while in the current state.
> 
> State machines are wonderful devices for mapping business 
> rules where "this process can only happen in these cases".
> 
> In my case, there is a table of events that have occurred in 
> the claim.  These events display the entire history of the 
> claim and are the focal point of the claim processing.  The 
> events channel the user, allowing them to do what makes 
> sense given where we are in the processing sequence, and 
> preventing doing things that make no sense given the current 
> state of the claim process.
> 
> The user can examine the event table and see what events 
> have transpired, the sequence of events, the dates, memos 
> about those events etc.  We even create events from outside 
> processes such as the mail merge process creates an event 
> "letter sent" with the name of the letter, who it was sent 
> to etc.
> 
> State machines, check them out.  They might just solve that 
> thorny process control problem that you are facing.
>