www.textroad.com
*Corresponding Author:Umair Abdullah, Assistant Professor, Barani Institute of Information Technology, PMAS-AAUR, Umair Plaza, Sixth Road, Rawalpindi, 46000, Pakistan. Tel.: +923005341053; Fax: +92519290409, Email: [email protected]
Knowledge Representation and Knowledge Editor of a Medical Claim
Processing System
Umair Abdullah
a,b,*, Aftab Ahmed
a, Mohammad Jamil Sawar
b,c a FUIEMS, Foundation University, Islamabad, Pakistanb Barani Institute of Information Technology, Rawalpindi, Pakistan c Faculty of Engineering and IT, Northern University, Nowshera, Pakistan
ABSTRACT
Most of the research work in the area of knowledge representation does not focus on implementation environment of the knowledge base. Hypothesis of this paper is that implementation environment/ language/ tool, is also critical along with proper representation technique for success of a knowledge based system. ‘Production rules’ is a useful knowledge representation technique, suitable for task specific knowledge. This paper describes a successful applied scientific research work carried out in medical domain, resulting in a unique and useful system. A rule based expert system has been developed to identify errors in medical claims. Structured Query Language (SQL) has been used for implementation of production rules. Nowadays, SQL is widely used in almost every software system which is related to database. Besides rule engine, a rule editor has also been developed to facilitate domain experts to feed their knowledge in the system. Success of the system is primarily because of implementation methodology/ environment, adopted for development of the system and knowledge editor provided to the domain experts. Although current system has been developed for medical claim processing domain, but it can be easily modified and applied to any real life problem domain.
KEY WORDS: Artificial Intelligence and its applications, Rule Based Systems, Medical Claim Processing, SQL.
1. INTRODUCTION
Knowledge representation is an area of Artificial Intelligence (AI) concerned with depiction of knowledge in a system. There are many knowledge representation techniques like semantic nets, production rules, frames, scripts, and ontologies. All these techniques are conceptual models of knowledge, independent of the implementation tools and techniques. AI systems (knowledge based systems, rule-based systems, expert systems, intelligent systems etc.) use these techniques to signify knowledge in them. For example in CYC, knowledge is in the form of logical sentences. Further it is stated and organized in frames [1]. Frames are primary way of storing propositions in CYC [1]. CYC is concentrating on actual reality instead of targeting the knowledge source; this is also the main concern of ontological representation [2]. According to Guarino [2], Ontologies are task independent knowledge bases. Since the beginning of nineties ontologies have become a popular research topic investigated by several Artificial Intelligence research communities, including knowledge engineering, natural-language processing and knowledge representation [3]. Similarly, attempts have been made to reconcile production systems and logic programs without reducing one to the other, building on the strengths of each [4].
‘What is knowledge representation’ is best answered by R. Davis in terms of five distinct roles it plays [5]. First, a knowledge representation is most fundamentally a surrogate, a substitute for the thing itself. Second, it is a set of ontological commitments, that is, representation of real world. Third, it is a fragmentary theory of intelligent reasoning, inferencing. Fourth, it is a medium for practically efficient computation, that is, the computational environment in which thinking is accomplished i.e. organizing information to facilitate inferencing. Fifth, it is a medium of human expression, that is, a language in which we say things about the world [5].
According to Studer [3] ontology is about making task independent representation of knowledge. For task specific representation, based on transfer model i.e. getting knowledge from domain expert and transferring it to system production rules have been dominant approach. Of all the knowledge representation techniques, ‘production
rules’ are most suitable for representing task specific knowledge. Therefore they have been used in AI systems extensively. Production rules fulfill the requirements of usefulness, maintenance of an evolutionary knowledge, support for interactive consultation, competence, high performance and ease of use [6].
Problem: Most of the research studies related to knowledge/rule based systems do consider implementation environment. As correctly argued by Paul Skarek [7] knowledge engineering tools are normally not part of computing environment, and are costly. This thing creates a wide gap between theory and practice. To overcome this issue Paul Skarek [7] used database engine for his rule based system developed in 1996. But his system was not a full-fledged rule based system.
Proposed solution:
To bridge the gap between theory and practical environment, we have proposed to use SQL as implementation tool for the implementation of rule based system. Further we have proposed to provide a Graphical User Interface (GUI) based knowledge/rule editor to facilitate domain experts to supply their knowledge to a system to make it practically viable.
Aim of this paper:
This paper focuses on SQL knowledge representation and knowledge editor of the system developed as result of applied scientific research carried out in medical technology domain. The rule based system is developed to identify, errors, inconsistencies, and missing information, from medical claims, prior to insurance submission. In the system, rules are implemented in the form of SQL queries. Rule engine of the system use database server to run rule queries and perform rule actions.
Section 2 described literature review of systems developed in medical domain. Section 3 presented overall software architecture of the system. Section 4 showed very simplified design of rule engine developed in SQL in the form of stored procedures. Section 5 presented details about the knowledge base of the system. Attributes related to ‘rule’ and ‘meta-rule’ and ‘logical variable’ have been discussed. Knowledge editor of the system has been described in Section 6. Section 7 described rule development process before and after implementation of knowledge editor. Section 8 gave results and discussion. Conclusion in presented in the last section.
2. MEDICAL BILLING
While most of the research in healthcare is related to diagnosing problems, some research has also been carried out on administrative side of healthcare, like medical claim processing. Medical billing/medical claim processing is application domain of the system described in this paper. Medical billing is a process of submitting medical claims to insurances for the purpose of reimbursement, to healthcare provides (such as Surgeons, Physicians, Practicing Nurses, etc.), for the services rendered to the patients [8].
A medical claim is a collection of procedure codes (treatments/tests), diagnoses (diseases) codes and their relevant modifiers along with patient data. Generally medical practices employ experienced coders/billing executives to do billing.
When medical billing is carried out by healthcare providers by themselves, it is termed as ‘in-house billing’, which is not an easy job. To overcome difficulties of medical billing, most of the providers generally sign up with medical billing companies which are specialized in claim submissions and follow-ups. Follow-up normally occurs when a claim is rejected due to inconsistency in patient data, services rendered or some required information is missing.
Due to complexity of medical billing process, approximately 30% of claims are rejected initially. Of these rejected claims about 35% are rejected again. According to an estimate, about 10% of rejected claims are never paid [8]. By fixing preventable medical billing errors, payment collections can be increased, and rejections can be reduced. According to Carl [9] a well designed and technology supported medical billing procedure does not allow errors to propagate and will process over 90% claims to be paid after their first submission.
Many companies like Alcer©, CodeCorrect, PAMCC, HealthTech Fusion, SLC Software, Practice partner, Texas Medical Systems, Alpha II [10], have developed customized software to resolve claim rejection issue. Such software is generally known as ‘claim scrubbing software’. According to Abdullah et, al. [11] claim scrubbing is process of verification and checking of the medical claims for any potential errors and performs legitimate changes in information before it is sent to insurance payer. AthenaHealth implemented ‘claim scrubbing’ as a rule based system, instead of conventional software [12]. Team of experts is transforming medical billing knowledge in the form of rules. ClaimStaker is claim scrubbing application developed by Alpha II [13]. It is a tool to scrub claims against CCI Edits, LCDs and customized macros and rules.
3. ARCHITECTURE OF A RULE BASED SYSTEM FOR MEDICAL BILLING
Overall software architecture of a data mining driven learning apprentice system (i.e. our rule based system) for medical billing is presented by Ahmed [14]. A simplified version of the system is shown in Fig. 1. Domain users are persons who inserts, update, and delete medical
claims and their related data from the database. Team leads & managers, manage all medical billing related activities like claim follow up, payment posting, claim aging etc. of one or more medical practices. Billing executives, team leads and managers are the domain users shown at bottom left corner of Fig. 1. These domain users use medical billing related software like EMR, Encoder pro, and Billing-soft etc. to interact with operational database.
Operational database stores all the information of medical claims, patients, providers, practices, insurance payers, procedures, diagnosis, claim follow up information etc. Rule based engine applies medical billing compliance related rules on a claim when it is saved by the domain user into the database. Rule engine ‘scrub’ the claim to remove any potential medical billing related errors. Claim data is then submitted to insurance payers over the internet, represented as a cloud at bottom right corner of Fig 1.
Domain experts are persons with normally more than five years of experience in medical billing domain. They have in depth knowledge medical claim processing. They do research on web sites of government and private medical
billing related organizations and extract updated medical billing knowledge. Domain experts, being shown at upper left corner of Fig. 1, use medical billing related software to obtain various reports from data and to perform analysis.
They also use knowledge/ rule editor to update RBS rules defined in knowledge base of our rule based system, shown as main rectangular box in Fig. 1. It has four major components, i.e. Rule Based Engine, a machine learning module, knowledge base, and knowledge editor.
Focus of this paper is Knowledge/Rule editor and as it depends upon representation of rules, which has also been discussed.
4. DESIGN OF A RULE BASED ENGINE USING STRUCTURED
QUERY LANGUAGE
A simplified design of the rule based engine is shown in Fig. 2. Detailed explanation of the design has been published by Abdullah [8]. Rule engine flow is similar to that of Paul Skarek [7]. Skarek & Varga [7], working at CERN particle accelerator, developed a rule engine in structured query language (ORACLE database management system), for checking valid Beam Coordination Diagram.
It has been implemented in structured query language and serves the purpose of medical claim scrubbing. Our rule engine processes one claim at one time. Single claim data is input to the rule engine. It processes the claim in two phases.
In first phase, selection/ activation of applicable rules is done. Rules are selected on the basis of two criteria, firstly those rules are selected which have priority 25 or 75. Secondly meta-rules are executed one by one. When a Meta rule returns true then rules
Medical Billing Related Software Operational Database Knowledge Editor Rule Learning Module Knowledge Base Domain Users Domain Experts
Rule Based Engine (RBE) Insurances Claim data Payment info
Rule Based System (RBS)
Fig. 1 Simplified Architecture of Rule Based System for Medical Billing
Exit Start
Find Applicable Rules Claim Data
Execute Selected Rules
Report Error Found in Claim’s Data
Fig. 2 Simplified Design of Current Rule Based Engine
associated to it are selected/ activated. At the end of this phase all applicable rules have been activated (either due to priority or due to true condition of their Meta rule).
Second phase of rule engine is shown as second block, labeled ‘Executing Rules’ in Fig 2. In the second phase, rule engine applies all the selected rules one by one on a given claim and identifies data inconsistencies and errors. Each rule is like a check with some action part associated to it, implemented as “where” clause of a SQL query [15] The “select” portion of every rule query is predefined and same for all rules i.e. “select @rowcnt = count(*) ”. It has a user defined SQL variable i.e. @rowcnt, being assigned count of rows returned by the rule query. This select portion is attached automatically within rule engine while applying rules on a medical claim.
For example, ‘date of service’ is necessary for every claim. A claim is rejected if its ‘date of service’ is missing. Rule for this check will be implemented as follow;
Rule Query: where ‘<DOS>’ = ‘’
Where token ‘<DOS>’ is a logical variable. Its value comes from the claim that is being processed. A SQL query is associated with every logical variable. Rule engine get value of a logical variable by executing SQL query associated to it. Rule engine then replaces logical variable, in rule query, by its value.
Suppose date of service of a claim is missing. So rule query of above rule after replacing value of logical variable <DOS> i.e. empty string (‘’) is as follow;
where ‘’ = ‘’
Rule engine then attach predefined ‘select’ portion, and rule query becomes;
select @rowcnt = count(*) where ‘’ = ‘’
This query is a valid SQL query executable on database server. Rule engine then executes above query on database server and finds the value of @rowcnt. As “where” clause is true so @rowcnt user defined SQL variable will get value 1 indicating the error of “date of service missing” in given claim.
Suppose another claim is processed in RBS, having date of service equal to ‘07/30/2010’. Hence the value of <DOS> for this claim is ‘07/30/2010’. Rule query after replacing value of logical variable <DOS> will become:
where ‘07/30/2010’ = ‘’
After attaching fixed ‘select’ portion, rule query is as follow;
select @rowcnt = count(*) where ‘07/30/2010’ = ‘’
In this case @rowcnt, user defined variable, will get 0 value (as condition is false in “where” clause) thus indicating that error of “date of service missing” has not occurred in the given claim.
Action part of rule is also in ‘where’ clause of rule SQL query. Each production rule in knowledge base has its own action part. The critical rules stop faulty claims from submission, while non critical rules simply generate a warning message, and some rules automatically update claims to remove errors. Changes done by rules are according to the instructions approved by the corresponding providers.
5. KNOWLEDGE BASE OF THE SYSTEM
Knowledge is represented in the form of production rules, which is an extensively used technique, suitable for representing task specific knowledge. In our system production rules are implemented in the form of SQL queries. In order to gain efficiency, a common condition from a group of rules is separated and
defined as meta-rule. For example, suppose there are Fig. 5 Attributes of Logical Variable
Logical Variable
Variable Symbol: Name of logical variable to be used in meta-rules and rules.
Description: English description of claim attribute for which the logical variable is defined.
Query: A SQL query to fetch the value of logical variable from database.
Fig. 4 Attributes of Production Rule Rule
Rule Name: a symbolic name to refer rule.
Description: Information description for which rule is defined.
Condition: rule condition in the form of SQL query. Meta-rule name: to whom a rule is associated. Priority: An integer to refer importance of a rule. Status: To identify between active and inactive rules. Reference: How the rule communicate to RBS team Owner: Domain expert who has understanding of the rule.
Fig. 3 Meta-rule
Meta-rule
Meta Rule Name: a symbolic name to refer meta-rule
Description: Information description for which meta-rule is defined
Condition: meta-rule condition in the form of SQL query
ten rules which belong to a practice X. A meta-rule will be defined performing the check that claim under processing belongs to practice X. During the processing of rule engine, if this meta-rule returns true on a claim, only then those ten rules, which are associated to it, will be activated. Use of Meta rules is an old concept [10] and used in different domains [16]. Knowledgebase of our RBS consists of three entities i.e. meta-rules, rules and logical variables, stored in their respective tables.
Rule attributes provide a declarative way to influence behavior of a rule. Attributes of meta-rules, rules and logical variables, along with their description are given below in Fig. 3 Fig. 4 and Fig. 5. Suppose a provider of practice X wants following Instruction to be followed for his/her billing:
“For primary insurance Health Fist, if location is ABC then billing physician should be Dr. Doe”
This instruction has been sent to the rule development team, in an email on 06 March 2010. It can be implemented as a rule in our RBS, so that a claim violating it should be blocked from submission to insurance. Now as this instruction is only for practice X i.e. not applicable to all of the practices, so a meta-rule that this check should be applied only to the claims of practice X is needed.
Meta-Rule:
Meta Rule Name: mrPracticeX
Description: Claim belongs to practice X.
Condition: ‘<Practice_code>’ = ‘X’
Meta-rule name ‘mrPracticeX’ can be any suitable symbol. We have used this because it is clear from name that this is meta-rule of practice X. We can define all the instruction from this practice under this meta-rule. Rule will be Rule:
Rule Name: rDOE
Description: For primary insurance Health First, if location is ABC then billing physician should be Dr. Doe.
Condition: where ‘<Pri_Insurance>’ = ‘515314’
and ‘<Location_code>’ = ‘500504’
and <Billing_Phy> not in (‘743’)
Meta-rule name: mrPracticeX
Priority: 50
Status: Active
Reference: Email on 11 March 2010
Owner: Irfan
Note that in SQL query i.e. rule condition, codes have been used for easy processing in database. In our system, code of Health first insurance is 515314, similarly code of Dr. Doe is 743 and location code of ABC is 500504. In above rule and meta-rule four logical variables have been used. These are defined as follow;
Logical Variable 1
Variable Symbol: <Prctice_code>
Description: Practice code of a claim
Query: select practice_code from claim_table where claim_no = @claim_no
Logical Variable 2
Variable Symbol: < Pri_Insurance>
Description: Primary insurance of the claim.
Query: selec primary_insurance from claim_table where claim_no = @claim_no
Logical Variable 3
Variable Symbol: < Location_code>
Description: Location code of a claim
Query: selec Location_code from claim_table where claim_no = @claim_no
Logical Variable 4
Variable Symbol: <Billing_Phy>
Description: Practice code of a claim
Query: selec billing_physician from claim_table where claim_no = @claim_no
In queries of logical variables @claim_no is a SQL variable, and its value comes from the claim, which is under processing in RBS. Values of above four logical variables are simple columns of claim_table, obtained by executing their respective queries. Those values are then replaced in meta-rule query and rule query thus producing result of the rule on any given claim.
6. KNOWLEDGE (RULE)EDITOR OF THE SYSTEM
Experts agree that knowledge acquisition and verification are among the most difficult problems associated with the development of knowledge-based systems [17]. At the time of building knowledge base, mistakes in our understanding of subject domain and weaknesses in used representation techniques are highlighted [17].
There are many companies which provide rule editors for adding/editing business rules and knowledge acquisition. A few of them are described below;
j.MD Solutions [18] is a tool for authoring, testing and processing expert knowledge bases in medical domain. It was originally designed for interpretation and validation of laboratory tests. Now, other medical or even non-medical domains can also be served. Today, j.MD Solutions is one of the most powerful software products for knowledge-based and rule-knowledge-based systems in medical domain. j.MD Knowledge Editor authors expert medical knowledge [18]. It organizes expert medical knowledge in hierarchies of knowledge bases, laboratory tests, diagnostic concepts and rules. It provides an
intuitive and easy-to-use graphical user interface.
OpenRules, Inc. [19]
provides a web
application that consists of two parts, data input
with rule engine
execution and online rules editing. Blue Fish
Development Group
provides Web Publisher. It is a browser-based, customizable tool that allows a business user to create web content. It has advantage over raw web page authoring tools by allowing a more secure enforcement of business rules.
EZ-Xpert [20], AI Developers, Inc.’s rapid application development
(RAD) environment
makes development of powerful rule based expert systems, simple enough for even the most novice computer user. An intuitive and
easy-to-learn interface walks through the steps to develop own rule bases while EZ-Xpert transparently generates the complex code. The rule base engineering techniques built into the product verify consistency of the knowledge during its building, thus minimizing the need for testing and debugging. Rule set editor of SAP America, Inc. allows editing “if-then” rules and preconditions. User can also set rule priority, override affectivity for rules [20].
Microsoft ships a robust business rule engine with Windows Workflow Foundation (WF) that can be incorporated into workflows to assist in managing business processes [21]. This business rule processing can be used in various capacities with Windows Communication Foundation (WCF) to enrich its message processing capabilities [21].
None of the rule editors described above, is associated with SQL queries. All of them have their own rule engines associated with own specific languages.
Fig. 6 Knowledge (Rule) Editor main window
List of Rules Main rule
developing area
SQL query generated
The knowledge (rule) editor developed during this applied scientific research, provides a graphical interface to domain experts to feed their knowledge. Now medical billing domain experts will perform role of knowledge engineers for building rules from their knowledge. Main window of rule editor is shown in Fig 6. It is used for developing of rules, meta-rules, and logical variables. It generates SQL queries of rules, meta-rules and logical variables by it, while users have to interact with graphical user interface only.
A list of rules is appearing on left side of the window in Fig 6. User can switch to meta-rules and logical variables by clicking their respective radio buttons present above the rule list. User can search and select any rule from the list in order to edit/modify/delete it. Data of the selected rule appears on main area of the form/ window.
Gray portion near bottom shows SQL query of the rule, generated by the rule editor. This SQL query is representation of a production rule. Upper half of the form shows attributes related to the rule. These includes rule name, description, status, meta-rule, rule owner, reference etc. Every rule name should be unique i.e. no two rules in our knowledgebase are allowed to have same name. It can be any meaningful symbol entered by the user. Description is piece of information in English describing the rule.
Other two important attributes are ‘reference’ and ‘rule owner’. Often it happens that when a rule is moved to production, it is challenged by some domain users. Reference attributes helps knowledge engineering team to track the documentary proof of knowledge source of the rule. And ‘rule owner’ defends the rule and convinces domain users about the authenticity and validity of the rule. In some cases, a rule needs to be modified or even fully roll backed from the production.
On main window, middle portion of the form (labeled as ‘Rule’) is the main rule developing area. It is working area of the user, where user can build/define rule conditions and action. If user wants to add more conditions, he/she can click ‘Edit’ button to open an information segment window shown in Fig 7. User can click a hyperlink to open rule condition window shown in Fig. 8, and build a rule condition. Last hyperlink, after ‘then’ is action part of the rule. It opens rule action window (not shown here), where user can select some predefined actions and input rule message.
Information segment window has two parts. Upper panel is the list of data attributes/columns related to claim, patient, insurance, practice, provider etc. Required information segment is included in a rule to define a rule condition. Popup menus (shown in Fig 7) have been provided to join multiple conditions with the help of logical operators i.e. ‘and’, ‘or’, ‘not’. From popup menu user can insert opening and closing parenthesis to make rule condition more logical. User can build conditions on
Fig. 7 Information Segment Window
Fig. 8 Rule condition window to insert condition operator and its operands
Fig. 9 Function Application Window
main rule developing area of either main window or information segment window. In rule developing area values are in the form of hyperlinks. When a user clicks the hyperlink, a rule condition window opens up as shown in Fig. 8.
A condition is basically collection of conditional operator in the middle, left operand and right operand on left and right side respectively. Rule condition window allows the user to build a condition. Left operand is normally a logical variable associated with information segment, which was added in the rule on information segment window. Right operand can be another logical variable or a single specific value, like, in example rule of previous section, insurance code of Health First i.e. 515314 (a specific value) used as right operand in one of the rule conditions.
Right operand can be a list of more than one values when user select ‘in’ or ‘not in’ as conditional operator. Right operand can be two values when user chooses ‘between’ operator.
On rule condition window (shown on Fig 8.), ‘apply function’ button is available on both sides of conditional operator. When user clicks this button, Function application window opens up. It is shown in Fig 9.
A list of commonly used SQL functions is provided in ‘Functions’ portion in the form of two rows of radio buttons, shown on left side of function application widow in Fig 9. Some other functions are also included in list box present below these radio buttons. Argument text box becomes active in ‘arguments’ portion, when a function requires additional argument. User can apply function by checking its radio button and clicking ‘apply’ button. Applied function along with its arguments appears in applied functions’ list present on right side of function application window shown in Fig 9. In this way user can apply many functions or even same function multiple times. User can remove a function by selecting it from applied function list and clicking the ‘remove’ button.
Final output value along with applied functions is shown in output text box present at top area of function application window. Functions are applied in SQL syntax. When ‘ok’ button is pressed, value appearing in output text box will be returned as left value or right value on rule condition window.
In this way multiple rule conditions are built on information segment window, forming condition portion of the rule under development. Action part of the rule is added using information segment window. When check box of ‘rule action’ present at upper left corner is checked, a list of all available actions is displayed in information segment window shown in Fig. 7. User can select one action at one time to complete a rule. On pressing ‘OK’ button of information segment window, rule is displayed on main window in same format. SQL query of the rule is
generated and displayed in gray area near bottom of main window shown in Fig. 6.
This is flow and working of forms and windows of knowledge editor. Besides development of rules, knowledge editor has following modules;
Fig. 10 Serialized Rule in XML form
A. Rule Management
Knowledge editor facilitates the users in management of rules. With the help of knowledge editor user can activate, deactivate rules present in production. User can move rules from development server to production server. When user moves a rule to production, then RBS copies all its relevant from development server to production server.
B. Rule Serialization
In knowledge editor, different classes like Rule, Rule Condition, Query etc. have been used. From objects of these classes, SQL queries of rules are generated and saved in the database.
To reload saved rule in knowledge editor i.e. to create objects of Rule and Rule Condition, there are two options. Firstly, write a translator module which could build class objects from SQL query of the rule. Secondly, we can create snapshots of class objects in XML form and save them, known as ‘serialization’. Then create class objects from XML form later on, known as ‘de-serialization’. We are using second approach, as this feature is provided by Microsoft .Net programming environment and is known as ‘Serialization’. So when a rule is created in our knowledge editor, a serialized image of the object of ‘Rule’ class is also created in XML form, along with SQL query of the rule. A serialized Rule, along with Rule Conditions is shown in Fig. 10. This XML form is then de-serialized to create object of ‘Rule’ class, when a rule is loaded in knowledge editor, where user can edit this rule.
In future, these serialized rules in XML form can be shared, sent to other organizations and can be used as a commodity in knowledge trading.
7. RULE DEVELOPMENT PROCESS
Advantage and benefit of knowledge editor can be visualized in rule development process before and after the implementation of knowledge editor, shown in Fig. 11 and Fig. 12.
Flow of rule development process prior to knowledge editor is shown in Fig. 10. Domain user initiate a rule by sending piece of knowledge to rule development group i.e. dev-group. It is a group of domain experts, with normally more than five years of experience and in depth knowledge of medical billing. Rule development group then do analysis of information received, confirms its validity and send the refined information to RBS team for development of
rule. Since there was no user interface available for them, so they were dependent on RBS team for development of rules. RBS team, consisting of persons with knowledge of SQL programming, was dependent on rule development group for knowledge of application domain. RBS team was using Microsoft SQL Server Management Studio 2005, to write production rules in the form of SQL queries. After some loops of correspondence and sign-off from dev-group, RBS team moved rules to production server. This process was time consuming and involves chances of error, miscommunications and false assumptions.
Fig. 11 Rule development process flow before Knowledge Editor.
Fig. 12 Rule development process flow after Knowledge Editor.
Flow of rule development process after the implementation of knowledge editor is shown in Fig. 12. Now it is more simplified, efficient and less error prone.
Rule initiator sends piece of knowledge to domain experts. Domain experts of rule development group can develop rules with the help of graphical user interface of knowledge editor software, which is developed and maintained by RBS team. Rule creation process has speed up due to knowledge editor. Table 1 shows monthly count of rules created prior to the implementation of knowledge editor i.e. January, February, March, April. During these months total of 208 rules were created with monthly average of 52 rules.
Table 2 shows number of rules created, in four months, by rule development group using knowledge editor. A total of 366 rules created with monthly average of 91 rules. Note that during first month of knowledge editor implementation i.e. May, 32 rules are created, as rule development group was learning to use the knowledge editor.
8. RESULTS AND DISCUSSION
Enhanced usability and effectiveness has been achieved by developing rule based systems in relational database environment. Using a database environment helped us bridging the gap between data and knowledge thus increasing usefulness of software and gain wide acceptance.
Due to RBS, claim rejection rate has been reduced. Prior to the implementation of RBS, graph of daily rejections for the month of January is shown in Fig. 13. Daily average rejection rate is 4.98 % i.e. out of 100 claims approximately 5 claims got rejected. After the implementation of RBS, graph of daily rejection rate is shown in Fig. 14, with average daily rejection rate of 2.70 %. Rejections have been reduced by 54%. Success of our rule based system is mainly due to implementation environment i.e. SQL database. Rules are implemented in the form of SQL queries. Thus applying rules on domain’s data is easy and fast.
With the help of RBS, we have been able to do faster automation of special instructions, knowledge oriented checks and corrective actions. Process remained dependent on developers and SQL programmers till the development of knowledge editor. With Knowledge/ rule editor we got faster rule development process. Now domain experts, having no knowledge of SQL queries, develop rules. While underlying queries are generated by the knowledge editor. With almost every rule based system suggesting a new rule language will bring us back to 1980s, when there was abundance of specialized/ generalized tools and expert system shells [22], none of them with wide spread/ global acceptance and use.
9. CONCLUSION AND FUTURE DIRECTIONS
Relational database environment is widely used for storing and managing huge volumes of organized data. In order to make rule based systems more useful their implementation should be done in relational database environment. As success of our RBS system is primarily due to implementation of rules and rule based engine in relational database environment. Building a knowledge base of production rules in the form of SQL queries help in applying domain knowledge more efficiently. It also facilitates to keep production rules as part of data (instead of code). This implementation methodology has helped to achieve flexibility and usability.
Further improvement in effectiveness and efficiency has been achieved by developing knowledge editor for the system. Development of knowledge editor is also dependent upon implementation environment of production rules. In our case, rules are represented as SQL queries therefore knowledge editor is generating SQL queries of the rules.
Implementation of rule based system in relational database environment guides to a well defined knowledge engineering process. The goal of Knowledge Engineering (KE) is similar to that of Software Engineering i.e. turning the process of constructing knowledge base systems from an art into an engineering discipline. This requires the analysis of knowledge base building and maintenance process itself and the development of appropriate methods, languages, and tools specialized for developing knowledge base systems [3]. As knowledge is upper level of data, so knowledge engineering process of AI systems should patch up with database tools and languages.
Table 1: Number of rules created without Knowledge Editor
Months No. of rules
January 52
February 58
March 41
April 57
Table 2: Number of rules created with Knowledge Editor
Months No. of rules
May 32
June 68
July 139
August 127
A rule debugger can be future extension of knowledge editor. Debugger will help user in finding and removing errors in rule itself. It will provide step by step matching of rule conditions, thus will help the rule developer in finding logical mistakes also. Rule learning module. Besides data mining algorithm of rule extraction from historic data, a deductive learning module can be included in the system to learn more rules, verify existing ones and find conflicts and overlapping of existing rules.
Rule performance
modules can also be an extension in our rule based system. Constant and continuous performance measurement of rules is very important for the success of the system. With knowledge editor, hundreds of rules being added by rule development group monthly. Initial success may turn into failure, if bundles of useless rules got inserted into the system. To keep the system efficient, rules with zero impact should be removed from knowledge base of the system.
Mining of association rules has been worked out in medical billing domain
[23]. Extraction of
production rules from medical billing data warehouse can be a future extension of this paper.
ACKNOWLEDGMENT
This research work had been supported by Higher Education Commission of Pakistan under ‘5000 – indigenous PhD Fellowships Scheme’. Many thanks to USA based medical billing company for providing excellent research environment. Name of the company has not been disclosed due to ‘Cooperate Identity Disclosure Policy’ of the company.
REFERENCES
1.Elkan, C., & Geiner, R. 1993. Review of Building Large Knowledge-Based Systems: Representation and Inference in the Cyc Project, Artificial Intelligence, 61:1, 95-104.
2.Guarino, N. 1995. Formal Ontology, Conceptual Analysis and Knowledge Representation, International Journal of Human and Computer Studies, Elsevier, 43(5/6): 625-640.
3.Studer, R., Benjamins, V. R., & Fensel, D. 1998. Knowledge engineering, principles and methods, Data and Knowledge Engineering, Elsevier, 25(1-2):161–197.
4.Kowalski, R., & Sadri, F. 2009. Integrating Logic Programming and Production Systems in Abductive Logic Programming Agents, In Proceedings of The Third International Conference on Web Reasoning and Rule Systems, Chantilly, Virginia, USA.
5.Davis, R., Shrobe, H., & Szolovits, P. 1993. What Is a Knowledge Representation?, AI Magazine Volume 14 Number 1 (© AAAI) pp-17-33
Fig. 13 Daily rejection rate for the month of January 2010 i.e. prior to implementation of RBS.
Fig. 14 Daily rejection rate for the month of July 2011 (after implementation of RBS)
6.Davis, R., Buchanan, B., & Shortcliffe, E.H. 1977. Production Rules as a Representation for a Knowledge-base Consultation Program, Artificial Intelligence, 8, 15-45.
7.Skarek, P., & Varga, L. Z. 1996. Rule-Based Knowledge Representation Using a Database, Conference on Artificial Intelligence Applications, Paris, France, 21 - 22 Oct.
8.Abdullah, U., Sawar, M. J., & Ahmed, A. 2009a, Design of a rule based system using Structured Query Language, in Proceedings of 2009 Eighth IEEE International Conference on Dependable, Autonomic and Secure Computing (DASC09), Chengdu, China. pp 223 – 228 . DOI: 10.1109/DASC.2009.78
9.Carl, M. 2008. "Don't Leave Money on the Table - Use a Claim Scrubber." Don't Leave Money on the Table - Use a Claim Scrubber. 30 Sep. EzineArticles.com. <http://ezinearticles.com/?Dont-Leave-Money-on-the-Table-Use-a-Claim-Scrubber&id=1543716>.
10.Wicklund, E. 2008. "Alpha II brings 'claims scrubbing' to the medical billing market," http://www.healthcareitnews.com, July 31.
11.Abdullah, U., Sawar, M. J., & Ahmed, A. 2009b. Comparative Study of Medical Claim Scrubber And A Rule Based System, in Proceedings of IEEE 2009 International Conference on Information Engineering and Computer Science (ICIECS 09), Wuhan, China. DOI : 10.1109/ICIECS.2009.5363668
12.Richards, B., & Mullin, L. 2010. Automated configuration of medical practice management systems. US Patent no: US7,720,701B2. Date of Patent: May 18, 2010. Assignee: athenahealth, Inc. Watertown, MA, US.
13.Hazen, T. 2008. “Scrubbing Reimbursement Rates Clean” Alpha II Claim Staker solution (online) www.alphaII.com
14.Ahmed, A., Abdullah, U., & Sawar, M. J. 2010. Software Architecture of a Learning Apprentice System in Medical Billing. The 2010 International Conference of Computational Intelligence and Intelligent Systems, at World Congress on Engineering, 30 June - 2 July. (pp. 52-56), London, U.K.
15.Shortliffe, E. H. 1986. Medical expert systems-knowledge tools for physicians, West J Med.;145:830-9. 16.Schild, U. J., & Herzog, S. 1993. The use of meta-rules in rule based legal computer systems, Proceedings of
the 4th international conference on Artificial intelligence and law, p.100-109, June 15-18, Amsterdam, The Netherlands.
17.Miller, R. A. 1994. Medical Diagnostic Decision Support Systems - Past, Present, and Future, Journal of the American Medical Informatics Association Volume 1 Number 1 Jan/Feb.
18.http://wormek.org/jmd.jsp (web reference)
19.http://openrules.com/ExternalRulesFromGUI.htm (web reference) 20.http://www.ez-xpert.com/review.html (web reference)
21.http://msdn.microsoft.com/en-us/library/dd349784.aspx Matt Milner, "Windows Workflow Tutorial: Rules-Driven WCF Services", December, 2008
22.Melle, W. V. 1979. A domain independent production rule system for consultation programs, In International Joint Conferences on Artificial Intelligence - 79, pp. 923 – 925, Tokyo, Japan.
23.Abdullah, U., Ahmed, J., & Ahmed, A. 2008. Analysis of effectiveness of apriori algorithm in medical billing data mining, Proceedings of 4th IEEE International Conference on Emerging Technologies, Rawalpindi, Pakistan. pp 327-331, DOI: 10.1109/ICET.2008.4777523
