0 Comments

Recently one of the NY Times blog carried this news about Vanderbilt University Medical Center going in for the Ilog business rules management system The Doctor Will B.R.M.S. You Now – Bits Blog – NYTimes.com. Other health IT sites and the blogosphere picked up this news and were abuzz for a while with the potential of such systems.

From this:

image

To This:

image

One has to stop and ask what is so complex about rules for healthcare that expensive systems are needed to support them. Do we really need them?

Surely we need the capability to manage rules; the more familiar the users become with the system you the more rules seem to be spawned. Such BRM capabilities include preventing redundant rules to be created, to semantically identify rules with similar intents, to use similar semantic mechanisms to locate a rule which is most suitable for reuse in a situation etc.

Clinical decision making is based on results of clinical trials. The clinical trials almost never consider more than a few parameters at a time to reach a conclusion. Furthermore, rare are the clinical contexts where more than a few data items are evaluated to decided between several possible conclusions. Therefore the major need is not for the systems which can handle complexity but for the systems which allow exploiting the capability of the rules engines and repositories.

The most critical advantage a business rules system offers is to externalize the rules so that they can be changed even after the system has been developed and deployed. Preferably the logic and flow of the applications can be changed by subject matter experts possessing no programming skills.  In contrast, in the traditional systems the logic is buried inside hardened compiled code and is out of bounds for the ordinary users. It can only be changed by hugely expensive programming efforts. Not just the programming resources, the development effort requires the business experts to educate the programmers about the new logic they would like in their applications. In the interface between the clinicians and the programmers, either the former will need to learn about software technologies or the latter will have to be taught enough of medicine. The solution adopted in most situations is that clinicians end up spending significant amount of time teaching piecemeal clinical logic to the programmers. The BRM approach obviates the need to do so. However, if the users are to be the primary custodians of the logic of the applications we also need user-friendly tools. Most systems (commercial or open source) have done a poor job in providing such interfaces. The user interfaces have been step children of the BRMs. They have provided the lakes and ponds teeming with bounteous fish but have paid little attention to fishing nets and rods. Little wonder the users go hungry.

The GreEd (pronounced as greed) system was created with a different thinking. It started with thinking about how the users (clinicians) will find it intuitive to work with clinical logic. For GreEd, which stands for Graphical rule elements Editor, it does not even matter which underlying rule system is used since its internal syntax is mappable to the most commonly used logic elements of other rule representation approaches. GreEd boasts of an approach in which logic, even complex clinical logic, may be specified by simple drag and drop operations. Although GreEd started as a rule authoring tool (hence the name), it is more than a rules editor. It is a full rules management system. It is extensible to allow new logic elements (as operators) to be included to become one of draggable items available to create executable logic. The rules themselves use standards based data elements (ISO/IEC 11179), which allows semantic searching and navigating of the rules repository, besides some very interesting uses. Currently, its internal syntax has one mapping, to Java programming language but we plan to create mappings for other production rules syntaxes too.

A good user accessible authoring environment saves organizations time and money. We expect to exploit GreEd to get these benefits. Stay tuned for a more detailed post about GreEd sometime in not so distant a future.

Share

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>