Maximum depth of search (e.g., 2 could result in the inclusion of descendant scoping entities up to the grand children) A unique identifier characterized by 3 attributes: the identifier of the scoping entity; the business identifier within the scoping entity; and the version. Two identifiers are the same when these 3 attributes are equal. An EntityIdentifier must be globally unique. Enumeration of all concrete Entity types. InteractionIdentifier represents information that is transmitted as a part of an interaction to identify that interaction for logging and debugging purposes. The InteractionIdentifier consists of a scopingEntityId and an interactionId unique within the scopingEntityId. A submissionTime is also provided to help find the interaction. The Item Identifier (ItemIdentifier) consists of the Entity Identifier of its containing entity, as well as a String "itemId." The "itemId" attribute must be unique within the scope of the containing entity, and the complete ItemIdentifier (i.e., combination of containingEntityId + itemId) must be globally unique. Must be unique in context of containing entity. Language shall be specifiied as either a 2-character ISO 639-1 language code or a combination of a 2-character ISO 639-1 language code and a 2-character ISO 3166-1 geographical code, concatenated with a hyphen. Example valid language specifications include: "en", "en-US", "en-GB", and "fr". ISO 639-1 codes are available at http://www.loc.gov/standards/iso639-2/php/English_list.php, and ISO 3166-1 codes are available at http://www.iso.org/iso/english_country_names_and_code_elements. A scoping entity has a unique, fully-qualified identifier, which must start with lowercase English representations of one of the top-level Internet domain names, currently com, edu, gov, mil, net, org, or one of the English two-letter codes identifying countries as specified in ISO Standard 3166-1. Subsequently, the id must start by defining the domain name that is associated with the scoping entity (e.g., com.clinica, com.dbmotion, edu.duke, org.hl7). Subsequent identification within the domain associated with the scoping entity, if any, may be specified as is appropriate for the internal naming conventions by the scoping entity. A scoping entity may create hierarchical structures. SemanticPayload is identified by a semantic signifier and has a value that is expressed using the semantics defined by the semantic signifier. This is the base class for all service requests and contains an InteractionIdentifier. The abstract superclass for exceptions A EvaluationException is thrown when an exception occurred while trying to evaluate a KM. The InvalidDataFormatException is thrown when data are not consistent with the information model defined by a semantic signifier. A InvalidDriDataFormatException is thrown when trying to evaluate a KM but data provided for one of its Data Requirement Items has an invalid format. The InvalidTimeZoneOffsetException is thrown when the time zone offset specified is unrecognized. The time zone offset represents the offset from Universal Coordinated Time (UTC). The offset should be expressed as +/- hh:mm, e.g., 00:00, -05:00, +07:00 An InvalidTraitCriterionDataFormatException is thrown when a trait criterion is inconsistent with the information model specified for the trait criterion through the use of a semantic signifier. A RequiredDataNotProvidedException is thrown when trying to evaluate a KM but one of the required data requirement groups is not provided. The UnrecognizedLanguageException is thrown when the language is unrecognized. The UnrecognizedScopedEntityException is an exception that is thrown when the service receives a request regarding a scoped entity that is not recognized using the its specified entity identifier object. A scoped entity identifier consists of the triplet of business identifier, version, and scoping entity identifier. The UnrecognizedScopingEntityException is an exception that is thrown when the service receives a request regarding a scoping entity that is not recognized using its specified identifier. The UnrecognizedTraitCriterionException is an exception that is thrown when the service receives a request regarding a trait criterion that is not recognized using the its specified item identifier object. The UnsupportedLanguageException is thrown when the language is recognized but not supported. The InformationModelRequirement specifies the information models that (a) can or (b) must be used by DSS knowledge modules claiming conformance to this requirement. This information model requirement consists of one or more of the following: (i) allowedDataRequirement - specifies the superset of data requirement models and associated query models that can be used (ii) requiredDataRequirement - specifies the data requirement models and associated query models, if any, that must be used (iii) allowedWarningModelSSId - specifies the superset of models that can be used by the service to provide warnings regarding evaluations (iv) allowedEvaluationResultModelSSId - specifies the superset of evaluation result models that can be used (v) requiredEvaluationResultModelSSId - specifies the evaluation result models that must be used A DSS claiming conformance to this requirement must fulfill the semantic restrictions defined in the narrative specification. The superclass of all DSS semantic requirement sub-types. Enumerates concrete semantic requirement types. It specifies the a specific knowledge module trait requirement. Trait is identified by a scoping entity, the trait identifier (unique within the scoping entity), and the trait version. The requirement also specifies if the trait is required or optional for knowledge modules claiming conformance to the requirement. It specifies the list of the knowledge module traits that will or may be associated with all knowledge modules claiming conformance to the requirement. Traits are identified by the identifier of the scoping entity for the trait, the trait identifier, and the trait version. The requirement also specifies if the trait is required or optional for knowledge modules claiming conformance to the requirement. A SemanticSignifier uniquely specifies an information model A computable information model based on the use of an XML Schema Definition (XSD), zero or more Schematrons, an optional narrative guide to further restrict the model, and the name of the global element that serves as the root element of the information model. Note that an XSD used in this context must have the root element defined as a global element so that it can be directly used for automated instance validation. Other potential approaches to defining computable information models are possible (e.g., using Document Type Definitions), but this is the computable information model required for the DSS's XML Web Service Platform Specific Model. The name of the global element that serves as the root element for the information model. Location of the XML Schema Definition A ConformanceProfile consists of one or more supported functional profiles and one or more supported semantic profiles. A FunctionalProfile represents a list of supported service operations. Service profiles grouped by type. This object groups service profiles of a given type. Enumeration of all concrete Profile types. A SemanticProfile represents a list of the semantic requirements to which the service conforms. The superclass of all profile sub-types. Traits represent attributes of objects. In the DSS context, traits are used to describe knowledge modules. Whether a trait's values are language-dependent. The TraitCriterion object represents a criterion that can be applied to a knowledge module trait value. The identifier of a trait criterion consists of the EntityIdentifier of the parent trait plus an itemId that is unique within the scope of the EntityIdentifier of the parent trait. This object contains information about Consumer Provided Query Parameter objects that are used within a specific Data Requirement Item in its query instance. It contains the identifier of the Consumer Provided Query parameter and its path within the query instance. An unambiguous specification of the path to the CPQP in the query model. For XML Web service implementations, an XPath 1.0 expression shall be used for specifying the path. The response object of the getKMDescription operation in the Query interface. It contains different sections, each describing an aspect of the knowledge module. The knowledge module sections include traits and related knowledge modules. This object represents one of potentially several alternative information models for a KM data requirement item. This object specifies the expected information model for the data using a semantic signifier. Optionally, it may specify the semantic signifier of the query model and its instance. In addition, it may also specify one or more Consumer Provided Query Parameters that are used in the query. For each query parameter in use, it specifies its identifier and its path in the query. A KMConsumerProvidedQueryParameter defines a parameter within the query instance of a data requirement item which is unknown at design time and must be set by the consumer at runtime before knowledge module evaluation. It extends KMItem for common knowledge module item data like name and description. A KM Data Requirement Group consists of one or more data requirement items. The response object of the getKMDataRequirements operation in the Query interface. This object specifies the data requirement groups initially required for an iterative evaluation interaction, as well as any additional data requirement groups that may be needed depending on the results of the initial interaction. In addition, it extends its superclass for a list of Consumer Provided Query Parameter objects defined for the data requirement items of the knowledge module. A KMDataRequirementItem represents the specification of knowledge module required data from the external world. A data requirement item is specified in terms of one or more alternative information models. The semantics of a knowledge module evaluation result. The superclass of all knowledge module sub-items. For example, Data Requirement Group or Item. It contains the item identifier, which consists of the identifier of the knowledge module as well as a unique identifier within the knowledge module. It inherits name and description information from DescribedDO. Allowed values for Knowledge Module status. See technical specification for details. The KM successfully passed the QA tests. Can be executed. Precondition: the KM is syntactically valid. When a defined KM changes, a new version should be created. Draft KM. The KM can be used in the production environment. The KM definition doesn't match the KM specification. The KM was historically promoted, but should not be used any more. A Knowledge Module trait value The DataRequirementCriterion is an object representing a knowledge module search criterion about Data Requirement Items. It contains a semantic signifier of the data information model and a list of allowed query information models. Each information model, data or query, is identfied using its semantic signifier identifier. A knowledge module is considered to have satisfied the criterion if both of the following are true: (i) at least one of the Data Requirement Items belonging to the KM uses the specified information model, and (ii) the Data Requirement Item does not use a query model, or it uses one of the query information models specified. If all of the specified evaluation result semantics are supported by a knowledge module, then the knowledge module is considered to have satisfied the criterion. The abstract base class for a KM criterion. Type of a relationship between two Knowledge Modules. The source KM provides one or more of its evaluation results to the target KM for usage as an evaluation input. The source KM provides one or more of its evaluation results to the target KM for passing the evaluation result through to the consumer. The source KM uses one or more of the evaluation results from the traget KM as an evaluation input. The source KM passes through to the consumer one or more of the evaluation results obtained from the target KM. The source KM was superceded by the target KM. That is, the target KM should be used instead of the source KM if possible. The source KM supercedes the target KM. That is, the source KM should be used instead of the target KM if possible. The KMSearchCriteria is an object containing knowledge module search criteria. A criterion used to include KMs into the search result list and/or increase the KMs' search score. A criterion used to exclude KMs from the search result list and/or reduce the KMs' search score. The score resulting from a search for relevant KMs. Must be an integer from 1 to 100. A KM meeting all client search criteria shall have a score of 100, while a KM that does not meet all client search criteria shall not have a score of 100. Implementations of the scoring mechanism are vendor-specific. One suggestion is to make the score the % of criteria that match. If a KM has one of the specified statuses, then the knowledge module is considered to have satisfied the criterion. If the trait criterion is satisfied, then the knowledge module is considered to have satisfied the criterion. Specification of which KM traits to include in the the search result. Specifies the maximum number of KMs to return in the search result. Must be greater than or equal to 1. The RelatedKMSearchCriterion is an object representing a criterion on the relation type between knowledge modules. A knowledge module satisfies this criterion if it has a relation of type relationType to at least one of the specified knowledge modules. For the purpose of searching, the specified KMs shall be considered the target of the relationship. In other words, the DSS shall look for KMs that fulfill the following pattern: [the KMs returned by the search] [relationship type statement] [target KMs]. For example, if the relationship target KMs are KM A and KM B, and the search relationshipType is SUPERCEDES, then the DSS must look for KMs that supercede KM A and/or KM B. Must be specified Specification of the semantics used to convey the evaluation result(s) of a knowledge module. A list of knowledge modules. List of KMs, ranked by relevant (most relevant KM listed first). Note that KMs fully matching client search criteria (i.e., with a score of 100) may still have relative relevance expressed through the order used. This object contains information about the identifier of the related knowledge module and the relation type. The direction of the relationship uses the following pattern: [this KM] [relationship type] [related KM]. E.g., if this KM = KM A, related KM = KM B, and relationship type = USES_EVALUATION_RESULTS_FROM, then KM A uses evaluation results from KM B. The DataRequirementItemData is an object containing data for a particular data requirement item passed as input for a KM evaluation request. The EvaluationRequest is an object containing evaluation request of one or more knowledge modules in a non-iterative fashion. The EvaluationRequestBase is the superclass of all knowledge modules evaluation requests. It contains the data passed as input for evaluating one or more knowledge modules. The client's time zone offset from Universal Coordinated Time (UTC). This offset is expressed as +/- hh:mm, e.g., 00:00, -05:00, +07:00. Note that the client's time zone offset cannot be used to determine a geographical time zone. Unless otherwise specified, all time-stamped data provided by the client will be assumed to have this time zone offset. The EvaluationResponse is an object containing responses of evaluating knowledge modules in a non-iterative fashion. It contains a list of knowledge module evaluation responses reaching final conclusions as well as a list of knowledge module evaluations with intermediate conclusions due to insufficient data. The EvaluationResponseBase is the superclass of all evaluation responses. It contains a list of knowledge module evaluation responses reaching final conclusions. The FinalKMEvaluationResponse is an object containing final conclusions of a single knowledge module evaluation response. The IntermediateKMEvaluationResponse is an object that identifies what further data requirement groups were needed for reaching a final conclusion through the knowledge module evaluation. The IntermediateState contains contextual information regarding previous evaluation iterations for a knowledge module. The class implementations are vendor-specific. The IterativeEvaluationRequest is an object containing evaluation request of one or more knowledge modules in an iterative fashion. The IterativeEvaluationResponse represents the responses from knowledge module evaluations conducted in an iterative fashion. It contains a list of knowledge module evaluation responses reaching final conclusions, as well as a list of knowledge module evaluations responses reaching intermediate conclusions due to insufficient data. This object differs from the EvaluationResponse object in that it also provides intermediate state data in the case that a final conclusion could not be reached for a knowledge module. The IterativeKMEvaluationRequest is an object containing information of a single knowledge module evaluation request in an iterative fashion. It contains information from a previous evaluation iteration. The IterativeKMEvaluationResponse is an object containing intermediate state of a single knowledge module iterative evaluation response. It contains contextual information of the evaluation process so far. @see IntermediateKMEvaluationResponse The KMEvaluationRequest is an object containing information of a single knowledge module evaluation request in a non-iterative fashion. The KMEvaluationRequestBase is the superclass of a single knowledge module evaluation request. It contains information about the knowledge module identifier to evaluate. The following are valid ways of specifying the version number of a knowledge module to run: (i) the specific version number (e.g., 2.1.0): this will result in the evaluation of version 2.1.0; (ii) the specific major and minor version, with * as the revision number (e.g., 2.1.*): this will result in the evaluation of the highest revision with the specified major and minor version number (e.g., 2.1.0, 2.1.1, or 2.1.2, depending on the latest available revision); and (iii) the specific major version, with * as the minor version and * as the revision number (e.g., 2.*.*): this will result in the evaluation of the highest minor version, and the highest revision within that minor version (e.g., 2.3.1, if the highest minor version within major version 2 is 3, and the highest revision within version 2.3 is revision 1, then 2.3.1 would be used). The KMEvaluationResponse is the superclass of a single knowledge module evaluation response. It contains the knowledge module identifier as well as warnings. The KMEvaluationResultData is an object containing a knowledge module's evaluation result data.