The ServiceDefinition describes a unit of decision support functionality that is made available as a service, such as immunization modules or drug-drug interaction checking. The ServiceDefinition describes a unit of decision support functionality that is made available as a service, such as immunization modules or drug-drug interaction checking. If the element is present, it must have either a @value, an @id, or extensions An absolute URI that is used to identify this service definition when it is referenced in a specification, model, design or an instance. This SHALL be a URL, SHOULD be globally unique, and SHOULD be an address at which this service definition is (or will be) published. The URL SHOULD include the major version of the service definition. For more information see [Technical and Business Versions](resource.html#versions). A formal identifier that is used to identify this service definition when it is represented in other formats, or referenced in a specification, model, design or an instance. This is used for CMS or NQF identifiers for a measure artifact. Note that at least one identifier is required for non-experimental active artifacts. The identifier that is used to identify this version of the service definition when it is referenced in a specification, model, design or instance. This is an arbitrary value managed by the service definition author and is not expected to be globally unique. For example, it might be a timestamp (e.g. yyyymmdd) if a managed version is not available. There is also no expectation that versions can be placed in a lexicographical sequence. A natural language name identifying the service definition. This name should be usable as an identifier for the module by machine processing applications such as code generation. A short, descriptive, user-friendly title for the service definition. The status of this service definition. Enables tracking the life-cycle of the content. A boolean value to indicate that this service definition is authored for testing purposes (or education/evaluation/marketing), and is not intended to be used for genuine usage. The date (and optionally time) when the service definition was published. The date must change if and when the business version changes and it must change if the status code changes. In addition, it should change when the substantive content of the service definition changes. The name of the individual or organization that published the service definition. A free text natural language description of the service definition from a consumer's perspective. Explaination of why this service definition is needed and why it has been designed as it has. A detailed description of how the module is used from a clinical perspective. The date on which the resource content was approved by the publisher. Approval happens once when the content is officially approved for usage. The date on which the resource content was last reviewed. Review happens periodically after approval, but doesn't change the original approval date. The period during which the service definition content was or is planned to be in active use. The content was developed with a focus and intent of supporting the contexts that are listed. These terms may be used to assist with indexing and searching for appropriate service definition instances. A legal or geographic region in which the service definition is intended to be used. Descriptive topics related to the module. Topics provide a high-level categorization of the module that can be useful for filtering and searching. A contributor to the content of the module, including authors, editors, reviewers, and endorsers. Contact details to assist a user in finding and communicating with the publisher. A copyright statement relating to the service definition and/or its contents. Copyright statements are generally legal restrictions on the use and publishing of the service definition. Related resources such as additional documentation, justification, or bibliographic references. The trigger element defines when the rule should be invoked. This information is used by consumers of the rule to determine how to integrate the rule into a specific workflow. Data requirements are a machine processable description of the data required by the module in order to perform a successful evaluation. A reference to the operation that is used to invoke this service.