IT support for e-Rulemaking
Working paper for Panel 2
Towards a New Generation of e-Rule-Making
(Hovy - Cardie - Fox - Wiederhold)
Gio Wiederhold
11Jan 2003
Rule making, rule retrieval and storage, rule validation, and processing of rules all rely on Information Technology (IT). Much if IT today is broadly understood, but certain aspects are still in flux. Some of these are relevant to the four phases of e-Rulemaking and use. This note will focus on those aspects, and also try to avoid overlap with other panel presentations.
The three phases of use of e-Rules, unfortunately, all pose differing requirements, and will limit the fourth choice.
1. Rule making must be supported by public discussion. For broad public dissemination, text is the representation of choice. All traditional rules also exist in textual form. Some structuring is imposed on text by layout into chapter, sections, and paragraphs, sometimes quite formally. Cross references are needed when the hierarchical layout is too strict or when multiple hierarchies apply, but an excessive an excessive use of cross references makes text hard to follow.
Good display of text helps, and can be automated by markup languages as SGML and HTML. Formatting can be adapted to devices in the hands of the consumer. Images can be added -- all too rarely now -- to clarify relationships and scope. Graphics will become more important if the next generation is to become involved.
2. Rule retrieval and storage interact. Textual retrieval is error prone. Synonyms and cross references cause incomplete retrieval, homonyms and lack of context excessive retrieval. Formulating queries becomes an art. A representation as XML can add meta information that aids retrieval by identifying context, roles, and cross referencing. Explicit recognition of context can clarify the meaning and scope of terms. Semi-automated conversion of well-structured text can be performed, but the result has to be carefully vetted.
Storage of XML is becoming well supported. Adequate tools are becoming rapidly available to manipulate XML representations. These also allows rearrangement and selection of textual and graphical material manipulation, allowing it to be presented according to local needs, including conversion to HTML. XML is Standards for tagging are also developing, but inconsistencies of tagging of source material will continue to exist and be accounted for. Global consistency will arrive later than Godot.
3. Rule validation for consistency, completeness, is not well handled by textual rule representation in either form. Logical If-Then rules are required. Contexts must be explicit. Textual terms become variables, labeled with context and scope. Computational demands are a concern. Systems of more than a few hundred conditional rules seem to be the limit now. Effective automation will require will definition of fairly narrow contexts.
Formal rule management has to be done carefully and bottom up. Validation tools are quite feasible within clear context, and limited context will allow trust to be established. Cross validation of rules from multiple contexts will require explicit mapping of terms. I will cite some examples and show why such mappings have to be conservative. Simple lexical matches are too error prone.
4. Rule processing will differ based on the representations shown.
Structured text can be attached, likely by clickable reference, to documents affected by rules. Such a service could avoid redundant work, where say applicants for permits or services are now unclear of the meaning of and limits of their forms and petitions.
The likelihood of getting the right, and only the right information is enhanced by having rules in tagged form. Since standard forms, prototype designs, etc., can be similarly tagged, and will define context. much more precision can ensue.
Having the rules in a logical representation will allow automatic and quantitative processing. It will also promote performance-oriented standards versus overly detailed rules, that often constrain applicants and designers. Testing for ADA requirements has been demonstrated. More generally. having adequate and safe construction requires analysis, now often supplanted by guesswork and excessive conservatism to avoid multiple design cycles. Similarly, rules for payment or reimbursement are often excessively complex. Much dissatisfaction in healthcare, both by the providers and consumers, arise from complex rules, that do not allow early estimation of total costs and even less of reimbursable costs by insurances that are carried.
I have also been asked to comment on privacy. In the rule-making process there will be public as well as private information. In order to let the public participate, one cannot deny access. I have argued that in many situations denial of access is an inadequate and crude approach. If we wish to protect the release of confidential information we must filter the released data themselves. Access control is limited checking vis-à-vis metadata, and inadequate for many data collections, certainly healthcare, but likely also the increasing data collections that will be accumulated in our computer-managed world. For more information see the
TIHI project on my webpages
http://www-db.stanford.edu/people/gio.html.------------------------- o ------------ o -------------------