Jon Udell makes a nice foray into the world of rules based inference engines with a screencast which shows how potential non-programmers (with enough time and enthusiasm) might write their own applications.
First, a little background on this one. My first engineering job was with a small Irish software company called
Expert Edge. At that time, expert systems had a certain cache; To this
raw graduate in the late 80’s, Crystal (a rules based development
engine) was home, and Peregrine Expert Systems on Earslfort Terrace
were the enemy. This list shows the number of shell languages around at the time. Expert Edge eventually morphed into Development Tools Inc, which was then bought by Wall Data. The eventual purchase by Wall Data was laid in those early days of Expert Edge, where 3270 work eventually became bread and butter.
Then and now – a lot of the examples often given of expert systems being developed and used are usually in the medical field, even though in reality, the Finanacial houses gave them the greatest use. If you took out an insurance policy or mortgage in Ireland at the time, chances are it was an "expert system" that recorded your details and spat out a nice printed quotation. Remember, this was the time when notebooks were called portables, floppy disks were floppy and hard disks were 20Mb.
So it was interesting to see Udell take the Accident & Emergency
(ER) environment as the basis for the July screencast. The most
interesting part of his conversation with Dr Donald Thomas – an
engineer turned physician – was the latters very clean line of
reasoning on the interaction between the medical worker, the patient
and input device – in this case a tablet PC.
His role is a pretty unique one; being able to know exactly what the
user needs and wants. In Dr
"it it changes the way you think, it won’t work"
If the user does not get this, then the system
remains unused. In the case of this system – the simple need is to
collect the information electronically. The paper system being used for
patient triage has been perfected for speed and reliability.
So the whole interface and program flow uses this maxim of what the users mind workflow is; The way
the questions are posed, ensures that all of the information is asked
(even though the user might be able to deduct without even
asking the question).
As was mentioned in the conversation, the triage system is an example of a forward chaining
rules engine – there is not much inference actually going on – "real" expert systems would normally infer their output.
At the end of the discussion, the guys talk about the technology
involved, data integration and extraction (HL7 support) and how if one
were to program a system using the mTuitive development environment,
how on might find it useful to figure out what type of a problem solver
you are – an outliner, a flowcharter or a narrator.
Can one be all three ?