Table 1: Condensed Functional Requirements for a Knowledge Repository. Requirement Categories and Examples of Functional Requirements are Included. The Requirements Seek to Capture Elements of the Knowledge Model, the Knowledge Authoring Environment, the Knowledge Sharing Environment, and the Repository itself. An As-Yet-Unrealized Goal is to Specify Functional Requirements for a Knowledge Execution Component of this Environment

Knowledge Delivery Model: Requirements
Capability	Discussion
The system will function using Symbolic Variables	A goal is to separate the logical manipulation of symbolic variables from the mapping of those symbolic variables onto (local) clinical data. Identifiers for symbolic variables are selected to be consistent with the thought processes and language of clinicians (i.e., last serum_glucose).
The system will function using Objects (again symbolically)
Time will be a Component of Variable/Object Collections.	All clinical data should retain its timestamp when rendered as a variable in decision logic. The timestamp is chosen to represent the point in time when the data value was current. (A discussion of time ranges and other, non-point time values will be postponed.)
Knowledge Repository
Capability	Discussion
Allows storage (upload) of decision modules.	Hopefully through a process that “normalizes” the chunks of logic. This could be accomplished by mapping onto a standard, interchange format.
Allows retrieval (download) of decision modules in a read-only mode.	This is for download of modules to test and perhaps use in a recipient system.
Supports check out of decision modules explicitly for either editing or edit-free reviewing.	The system would allow for checkout of logic or collections of logic for editing and other management functions. This would require an “author” level authorization. When decision logic is checked out for editing by one author, it cannot be checked out for editing by other authors. When altered logic is checked back in, it would receive a new version number.
Knowledge Authoring/Maintenance
Capability	Discussion
Supports views of decision modules in the repository’s native (XML) markup.	The assumption is that, at least part of the decision modules will be stored in a XML-tagged data model.
Supports views of decision modules in "user friendly" text-based format.	Converters should be present that will display the decision logic and metadata in an easily read textual format
Supports views of decision modules in graphical format.	Trees or flow diagrams can show the relationship between parts of the decision logic (families of rules or modules) used to create more complex, decision output (guidelines).
Knowledge Sharing Service
Capability	Discussion
Supports conversion from local knowledge models to a repository specific, medical rules interchange format (MRIF).	The goal is to find a robust "Interlingua" that will facilitate moving logical constructs from one executable form to another.
Supports conversion from the repository-specific, knowledge interchange format into forms executable in multiple knowledge execution environments.	Ideally, these knowledge execution environments would all have a local expression of the executable form in XML. This would allow most translations to be done using XSLTs.
Translators should accommodate rule models including all standard logical functions/structures.	A standard vocabulary of logical structures will need to be represented (Add Appendix).
Knowledge Execution Environment