Requirements - Clinical Decision Support Workbench

1.0 Overview

Existing rule authoring tools, intended to support the technical knowledge engineer, do not allow the typical health care professional to encapsulate their expertise easily and reliably. As a consequence, they often struggle transferring that expertise into production clinical decision support systems. Restoring clinical nuance that has been "lost in translation" results in significant expense and is a major reason that decision support at the point of care has yet to fullfill its potential.

A knowledge management platform that incorporates not only rule-based logic, but also predictive analytics and optimization algorithms, Sirona enables decision support models to use a range of reasoning strategies that clinicans instinctively use during routine care. This introduces futher translational challenges. Domain experts require an intuitive graphical tool to help them author detailed knowledge modules containing rules, guidelines, and other logic. Organizations subsequently need tools to help them to store, evaluate, manage and deploy the resulting knowledge modules.

To this end, Sirona provides the following tools:

Tool Name	Functions
CDS Workbench	Provides a user interface to create knowledge module processes and browse available processes. Simplifies the creation of complex content by representing clinical tests, activities, and procedures as objects in drag-and-drop graphical editing environment. Saves defined processes and their metadata to the Knowledge Module Repository.
Knowledge Module Repository (KMR)	Provides a database where rules, knowledge modules, and models are stored. Provides a search-and-select mechanism using metadata that labels the knowledge modules when saved. Provides for storage of knowledge module metadata. Accessed only through CDS Workbench or the Knowledge Management Administration Portal.
Knowledge Management Administration Portal	Provides the knowledge engineer with tools and administrative functions required to configure and manage KMR infrastructure. Provides quality assurance life-cycle management capabilities needed to ensure safe and reliable knowledge modules upon deployment. Provides a means of setting up and administering configuration of process metadata.

For this version of Sirona, the CDS Workbench and the Knowledge Management Administration Portal are standalone and accessed independently. The Knowledge Module Repository is an infrastructure component that a user accesses only through one of these tools.

1.1 Terminology

Unknown macro: {table-plus}

Alert	Any message from CDS system.
Artifact	Another term for knowledge module.
CDS	Clinical Decision Support system.
CDSA	Clinical Decision Support Agent.
Decision point	Node at which author or clinician must choose among processing options.
Email	Electronic message user sends or receives.
Fact	Data that author is allowed to use within rules of knowledge module.
HIS	Healthcare Information System. Also, Hospital Information System
Human Task	Request for patient action, such as sending document or scheduling appointment; also, action requested by provider during clinical analytics or knowledge modeling.
KMR	Knowledge Module Repository.
Knowledge module	Combinations of both discrete rules and complex workflows that provide framework for decisions in knowledge modeling or clinical analytics processing.
LOINC	Logical Observation Identifiers Names and Codes; universal code system for identifying laboratory and clinical observations.
NwHIN	Nationwide Health Information Network; also NHIN.
Ontology	Structural framework for organizing information; renders shared terminology and taxonomy to model domain and define objects and concepts, and their properties and relations.
Rule	Group of one or more logical operations used to evaluate data from given patient or collection of patients.
SMS	Short Messaging Service, allowing exchange of short text messages between fixed line or mobile phone devices.

top

1.2 About This Document

This document describes the functional requirements for the main tools of the Sirona Knowledge Management Architecture: the Clinical Decision Support (CDS) Workbench and the Knowledge Module Repository. The Knowledge Management Administration Portal, a tool designed for the more technical engineer and the system administrator, is described in a separate document.

1.2.1 Audience

The following stakeholders are the audience for this document:

Business analysts and users
Architects, looking for a broad description of CDS Workbench
Developers

1.2.2 Document Organization

Section 1.0 describes the audience, scope, relevant terminology and reference documents, and documentation organization.

Section 2.0 describes the users allowed access to CDS Workbench and the functional requirements governing their roles.

Section 3.0 provides an overview of knowledge module authoring, and describes the components a user uses to create knowledge modules in CDS Workbench. It describes the CDS Workbench interface and provides the functional requirements for general access to, and display and usage of the various workbench components, including its three functionality panes and its pop-up editor for defining rule logic at decision points, start conditional events, and flow constraints.

Section 4.0 describes the functional requirements for the Knowledge Module Repository that persists the knowledge modules created in CDS Workbench and provides a means to search and select them easily.

Section 5.0 describes the functional requirements for the CDS Workbench run-time environment.

top

1.2.3 Related Documents

Account access functional requirements are described in Requirements - Unified Collaboration Portal.
Requirements for the Knowledge Management Administration Portal are described in Requirements - Knowledge Management Administration Portal.
BPMN modeling language specifics are described in the standard residing at http://www.omg.org/spec/BPMN/2.0/PDF/, in Object Management Group. Business Process Model and Notation, Version 2.0. January 3, 2011.
The Decision Support Agent is described in Requirements - Decision Support Agent.

Table of Contents

1.0 Project Overview
1.1 Terminology
1.2 About This Document

2.0 CDS Workbench Access
2.1 Enterprise Domain Expert Role
2.2 System Administrator and Knowledge Engineer Role
2.3 General Author Role

3.0 Knowledge Module Authoring
3.1 General Authoring
3.2 CDS Palette
3.3 Configuration Pane
3.4 Authoring Canvas

4.0 Knowledge Module Repository
4.1 General Repository Requirements
4.2 Categories Used to Tag Knowledge Modules

5.0 CDS Workbench Run-time Requirements

List of Figures

Figure 2-1: CDS Workbench Login Page
Figure 3-1: Sirona CDS Workbench Interface
Figure 3-2: Example of Process Design in Authoring Canvas
Figure 3-3: CDS Workbench Pop-up Editor

2.0 CDS Workbench Access

CDS Workbench access is governed by the general account access functional requirements described in Requirements - Unified Collaboration Portal. For this version of Sirona, CDS Workbench is accessed at a separate application URL and implements its own access control mechanism. In the future, Sirona will authorize domain experts and general non-technical users access to these tools from a dedicated Desktop portal tab within Provider Portal.

The following user roles are defined:

Enterprise Domain Expert
System Administrator and Knowledge Engineer
General Author, such as researcher or clinician

This section describes the functional requirements governing these roles. The following figure shows the CDS Workbench login page:

Figure 2-1: CDS Workbench Login Page

2.1 Enterprise Domain Expert Role

Enterprise domain experts are individuals responsible for the authoring of knowledge modules that are broadly applicable across an enterprise. These authors encapsulate desired organizational practices and behaviors; they author rules that are generally applicable to a given patient cohort. While they are also entitled to write rules particular to their own practice or functional requirements, their primary objective is to represent desired best clinical practices for the organization.

When using the CDS workbench, enterprise authors have access to workbench capabilities that are either unavailable to the general rule author or are less constrained in terms of their impact on other people, patients, or information systems. Enterprise authors have access to functionality enabling them to enroll patients in disease registries, write escalation rules capable of notifying other individuals within the organization, or create orders intended to be sent to recipients other than themselves. Enterprise authors are required to work closely with dedicated knowledge engineers and administrators to ensure that potentially powerful and far-reaching organizational knowledge modules are appropriately validated, tested, and reviewed for both clinical and operational appropriateness.

The following table contains the functional requirements that apply to authenticated enterprise domain experts:

ID	Description	Scope
3.1	Allow expert role to create, view, or modify any institutional rule.	Enterprise authors have access to knowledge modules that are unavailable to or less constrained for the general rule author.
3.2	Allow expert role to write personal knowledge modules.	Enterprise authors may need to write rules focused on their own practice, as opposed to enterprise rules.

top

2.2 System Administrator and Knowledge Engineer Role

The Sirona system administrator and knowledge engineer are technical users rather than clinical experts. Using the Knowledge Management Administration Portal, described in a separate document, these individuals are responsible for the administrative set up and configuration of the entire Knowledge Management infrastructure. They are the only individuals authorized to manage terminology or fact model resources used by either the authoring or run-time environments. They configure the Clinical Decision Support Workbench and oversee the quality assurance review that must be completed for all knowledge modules before they are deployed in the run-time environment.

ID	Description	Scope
3.3	Provide access to all workbench functionality and management tools.	When accessing management tool, system administrators see all institutional decision nodes and rule sets.
3.4	Provide option of displaying personal knowledge modules by searching for particular user name.	Out of scope for current version of CDS Workbench.
3.5	Allow system administrator's personal knowledge modules to be loaded into management tool.	Out of scope for current version of CDS Workbench.
3.6	Provide means to monitor administrative and performance metrics.	Metrics include Number and type of knowledge modules in repository Metadata associated with knowledge modules Average time for rule execution (out of scope for current CDS Workbench version) Number of rules in rule decision request execution queue (out of scope for current CDS Workbench version)

top

2.3 General Author Role

A general author is a domain expert authorized to create clinical decision support (CDS) modules that are not enterprise in scope. General authors do not typically possess the training or expertise required to define complex rules that have or may incur dependencies on other deployed assets. General authors have the ability to write rules directly into the production environment only if the resulting messages or alerts are directed only to themselves. Any rule that affects a patient or a coworker must be authorized by a knowledge engineer or system administrator before it can be deployed in the run-time environment. The rules that a general author is allowed to author are limited by scope and not by the type of reasoning they may employ.

The following table contains the functional requirements that apply to the general author:

ID	Description	Scope
3.7	Allow access to workbench tools to create personal workbench processes.	Rules that general authors create affect only themselves. Any rule that affects patient or coworker must be authorized by knowledge engineer or system administrator before deployment in run-time environment.
3.8	Allow option of displaying personal knowledge modules by searching for particular user name.	Out of scope for this version of CDS Workbench.
3.9	Allow general author's personal knowledge modules to be loaded into management tool.	Out of scope for this version of CDS Workbench.

top

3.0 Knowledge Module Authoring

CDS Workbench provides the non-technical domain expert with a tailored environment for creating and editing knowledge modules. Unlike most authoring environments, it harmonizes the orthogonal requirements of describing clinical workflow and defining rule logic into a single tool better suited to a clinician, who often does not appreciate the engineering distinction between a state-full process in a stateless rule evaluation. The editor hides the technical jargon and complexity of typical development environments to create an authoring tool that utilizes familiar clinical concepts and language.

The following figure provides an example of the Clinical Decision Support Workbench:

Figure 3-1: Sirona CDS Workbench Interface

top

3.1 General Authoring

CDS Workbench provides for a broad range of typical authoring environment functionality, including the ability to log in and authenticate, to search the underlying repository for previously authored knowledge modules, to create new ones, and to delete those that are no longer needed.

Repository search functions are displayed in a search drawer on the left when the editor is first opened. The search utility allows the user to browse a category tree where artifacts are grouped according to the clinical area that they were intended to address. This indexing occurs in a variety of ways. When authors first create a new module, they are given the opportunity to tag the artifact with domain metadata. For example, an author can manually indicate that a module is for asthma management, As a result, the module can be located in the clinical category of Asthma, providing a convenient way to browse all the rules related to a particular disease.

When a rule is saved, the module is automatically indexed by the components that were used within the rule itself. For example, if the rule involves medication orders or laboratory results, such metadata is automatically appended to the module. The workbench enables a user to search for rules that employ a particular rule component, such as the facts evaluated, the type of trigger used, or the the tasks recommended. This detailed search capability also allow the author to filter by the particular clinical context that a rule may require. If the author of the asthma rule, for example, restricts the scope to the cohort of children between the ages of two and five, the user can identify the cohort as a search parameter to retrieve only those asthma rules that have medication orders and are intended to help manage young children.

When an author selects and opens an appropriate knowledge module, the search pane collapses and the knowledge module displays in a three-paned editor, described in more detail below. The editing environment provides a toolbar at the top of the page for accessing editor functionality rapidly, for selecting module components to be included in the rule, and for defining the rule logic. When editing is complete, CDS Workbench allows the author to save the module to the repository.

3.1.1 General Authoring Requirements

The following table contains the functional requirements for authoring knowledge modules using CDS Workbench:

ID	Description	Scope
3.10	Provide editing tools for creating knowledge modules.	Modify Drools Designer to provide Workbench editing functions. Designer forms rules correctly and provides assistance during authoring.
3.11	Open existing knowledge module process or create new one.	New Process button allows creation of new process. Clicking New Process allows author to create process in authoring canvas. Double-clicking process under expanded Category tree opens existing process.
3.12	Provide tools to define rules and rule conditions.	Pop-up editor allows user to define conditions of outgoing gateway connections, or decision points. Author does not textually enter rules, but chooses from options provided by pop-up editor. Pop-up editor allows rules to be well-formed and provides assistance during authoring. Toolbar at top of page allows author to access editor functionality rapidly, to select module components to include in rule, and to define rule logic.
3.13	Persist process to repository once author has created it.	Save All Changes button provides this functionality. Upon save request, CDS Workbench analyses process structure. All classes and literals used by asset are identified using semantic reasoner: Out of scope for this version of Workbench. Resulting categories are attached automatically to asset, and saved with asset for later retrieval. Saved in this way, classes used to create process have corresponding matching concept ID. Constants are considered individuals, recognized within model.
3.14	Delete process.	Out of scope for current version of CDS Workbench.
3.15	Provide nested organization of Sirona knowledge categories.	Far left of Workbench interface provides tree of categories and processes organized under them. In this Workbench version, only one package is exposed to user, so no package tree is provided. Categories in tree are determined by ontology loaded into Workbench via Knowledge Management Administration Portal. Each menu provides nested taxonomy and rules.
3.16	Provide means to collapse or expand package and process tree.	Toggle triangle to left of package or process name.

The following subsections describe the main assets that an author uses in creating knowledge modules: CDS Palette, Configuration Pane, and Authoring Canvas.

3.2 CDS Palette

The CDS Workbench editing tool is divided into three panes: a left-side tool palette, a central authoring canvas, and a right-side properties configuration pane.

The tool palette displays the components that authorized users can use to draw knowledge module workflows. The palette provides template objects representing common domain concepts. For example, clinical data that might be used to trigger a rule are presented in a palette section called Fact Types, each icon representing data such as medications, allergies, or laboratory results. Icons can be dragged onto the canvas for further configuration. Similarly, easily identified objects also represent processing steps such as Decision Points or Tasks. Given the number of artifacts available, the tool palette groups its template objects into sub-collections, or drawers. A toggle allows the author to expose or hide the drawers.

Authors can drag and drop the objects onto a canvas and then link them to together by drawing connector lines to represent the sequence of execution that a module encodes. In this manner, a domain expert represents the process by which, for example, a laboratory test triggers a rule evaluation and then initiates the sending of an alert to a provider, e-mailing of the notification message to a patient, or both. The CDS Palette supports typical decision-support challenges intuitively and simply. It is not an all-encompassing authoring environment capable of modeling all clinical decision support use cases. In those situations where required functionality is not provided, the general author can consult with a knowledge engineer to build a fully developed knowledge module using an authoring environment tailored to the needs of the software engineer, such as the Eclipse jBPM 5 process editor.

The following types of objects are available in the left-side CDS Palette: Fact Types, Start/End Events, Decisions Points, Tasks, Cohorts, and Miscellaneous.

A Fact Type is a data object representing a clinical observation or collection of related information that the Sirona Architecture generates and presents to the Knowledge Management system for evaluation. Facts are typically clinical data about a patient, such as a new laboratory test, a diagnosis, or a medication. Facts, however, may be administrative in nature, such as an admission, or demographic fact. All fact types have a number of attributes or properties, such as the lab result value or units, a patient's name or address, or the substance that causes an allergy. To ensure the run-time system can unambiguously identify each fact and the exact clinical concept that the rule is evaluating, the workbench requires that each be uniquely assigned a terminology code from an established medical terminology such as SNOMED-CT, LOINC, or ICD9. A concept look-up capability, described in more detail below, is provided. Properly defined and semantically constrained Facts are used in the workbench to author rules that evaluate their attributes and reason about the resulting consequence. Available fact types include, but are not limited to:

Demographics
Immunizations
Lab results
Procedures
Diagnoses
Medications
Vital signs
Allergies
Encounters
Admissions
Cohort

A Start Event initiates a clinical rule and usually has a new clinical fact as a trigger. A Start Event may be a Signal Event that listens for new clinical facts before causing the subsequent rule process to fire (for example, if new lab result, then notify provider). After being triggered, the Signal Event passes the trigger on so that other Signal Events might be started (if new lab result, then store in EMR). Contrast this with Message Events: After the first rule process is initiated, the trigger is consumed and is not passed to other processes. Start Events may also be conditional. For conditional Start Events, fact attributes are further evaluated; only those facts whose data matches a conditional requirement are allowed to trigger the process (if new lab is platelet count, and count <80, then notify provider). And finally, a Start Event may be a Timer, which initiates the process at a defined date, or after a specific period of time.

End Events are events that bring a particular process to a conclusion. A simple End Event stops the process. A Signal End Event stops the process and initiates a Signal Event to notify subsequent processes that it has ended. Similarly, a Message End Event stops the current workflow and sends a Message Event. A Cancel End Event stops the process and rolls back to the last completed step in the knowledge module. Finally, a Terminate End Event cancels the whole workflow and returns the system back to its original state before the knowledge module executed originally.

A Decision Point defines the routing of data through the process. They allow an author to define the branching, forking, merging, and joining logic that controls a module's execution. Sirona allows three types of decision points:

Exclusive, or Data-Based Exclusive XOR Gateway: When used to split process flow, this Decision Point routes the sequence flow to one of potential many outgoing branches. When merging, it waits for one of the incoming data feeds to complete before routing the outgoing flow. The routing of the sequence flow is based on conditional logic that is embedded in the Decision Node using a provided rule editor.
Inclusive Gateway: When used to split sequence flow, this point activates one or more branches based on branching conditions. When merging, it waits for all active incoming branches to complete. The routing of the sequence flow is also based on conditional logic embedded in the Decision Node using a provided rule editor.
Parallel Gateway: When used to split sequence flow, this point activates all outgoing branches simultaneously. When merging parallel branches, the point waits for all incoming branches to complete before triggering the outgoing data flow. The routing of the sequence flow is also based on conditional logic embedded in the Decision Node using a provided rule editor.

Tasks are work items that represent actions or activities that a knowledge module generates when it is triggered. A task is a generic term for work that a knowledge module performs; tasks provide convenient, simple representations for collecting metadata and then bridging the logic and workflow of a knowledge module to the services that actually perform the work requested. For example, the email task allows the user to define the text of the message, the message priority, sender, receiver, and so on, and then submits the message to the mail system for delivery. Similarly, a medication order task assembles the required data for a prescription, and then communicates with the underlying pharmacy system to place the order. The author defines the when and what, the Task object executes the how. Common tasks include, but are not limited to the following:

Order
Appointment
Email
Page
SMS
Alert
Registration

A final section, called Miscellaneous, holds a small collection of artifacts that do not warrant their own drawer. These include connector, annotation, and grouping tools that are used during the authoring process.

Behind the scenes, the Workbench encodes all decision logic using Drools syntax, and all workflow descriptions using BPMN2 notation. This ensures that the code that the tool generates is compatible with the Sirona execution engine, Drools. If an organization uses different engines in its operational environment, workflow vendors can build a knowledge module parser and consume the BPMN2 description with little difficulty. Given the lack of a reference logic syntax, the conversion of Drools syntax to the preferred language may be more complex depending on the capabilities of the target syntax. Nevertheless, both process and logic are cleanly represented in the workbench knowledge module and a conversion to alternative architectures, while involved, is feasible.

3.2.1 CDS Palette Display Requirements

The following table describes the functional requirements for the CDS Palette:

ID	Description	Scope
3.17	Provide tree structure to display authorized components to use for creating knowledge modules.	Facts, decision points, tasks, and end events are components of this tree. This functionality resides in left-hand pane of Rule Editor interface. See CDS Palette Objects below for more information on CDS Palette sub-menus.
3.18	Allow author to choose component from palette.	Author drags and drops component to authoring canvas.
3.19	Collapse or expand CDS tool palette.	Toggle triangle to left of name. Toggle allows user to expose or hide template objects.
3.20	Semantically constrain data elements exposed to authors for building rules.	Allow appropriate terminologies, such as ICD9, SNOMED-CT, LOINC, and CPT, among others.

top

3.2.2 General Palette Object Requirements

The following table describes the general functional requirements that apply to CDS Palette Objects:

ID	Description	Scope
3.21	Show available rule components in series of sub-menus.	Possible sub-menus include Start Events Fact Types Decision Points (Gateways) Tasks End Events Cohorts Miscellaneous
3.22	Use standard graphical icons to depict rule components, where possible.
3.23	Adhere to BPMN2 notation wherever appropriate.	Workbench uses jBPM5, which is most current community version of jBPM project.
3.24	Allow modification of level of abstraction and graphic representation of knowledge artifacts.	Ensures visually consistent and intuitive authoring environment for non-technical clinical user.

top

3.2.3 Start Events Sub-Menu Requirements

The following table contains the functional requirements that apply to start events:

ID	Description	Scope
3.25	Support Message, Signal, Timer, and Conditional start events.	Message start event is out of scope for this version of CDS Workbench.
3.26	Force defined trigger, when processed by Message start event, to fire first process or rule evaluation.	Messaging is out of scope for this version of CDS Workbench. Trigger is then consumed and is no longer available or able to trigger subsequent processes and rules.
3.27	Allow message, when Signal start event processes event message, to initiate rule or process whose Drools LHS conditions match best, and continue to trigger other matching rules with lesser priority.	Messaging is out of scope for this version of CDS Workbench. Trigger designated as signal start event behaves like broadcast event, activating any rule or process with LHS match.
3.28	Allow initiation of evaluations on per-determined schedule or at specific time.	Timer based evaluations are only way to detect absence of event and are useful for Population Health or Disease Management programs.
3,29	Provide facilities for defining complex conditions through Conditional start event.	Facilitates more complex conditional requirements where one or more events must be combined and evaluated. CDSA can consume real-time clinical data delivered through medical device interfaces, such as streaming physiologic waveforms from a cardio-respiratory monitor.

Unknown macro: {table-plus}

top

3.2.4 Fact Types Sub-Menu Requirements

The following table contains the functional requirements that apply to Fact types:

ID	Description	Scope
3.30	Support clinical data objects to use in rule creation.	Fact types include Demographics Immunizations Lab results Procedures Diagnoses Medications Vital signs Allergies Encounters Admissions Cohort
3.31	Further constrain Fact object when dragged onto CDS Canvas.	Semantic constraints are defined via configuration pane, and by default through associated terminologies. Semantic constraints build foundation for semantic tagging based on concept names from defined ontologies. In future release, semantic tagging based on concept names will support semantic search of repository.
3.32	Provide tools to define restrictions for Fact attribute, such as valid/invalid ranges, valid/invalid values, and custom edition forms.	Out of scope for this version of CDS Workbench. This version of CDS Workbench provides one package and one working set for Sirona, but different categories for that configuration, based on ontology loaded into workbench.
3.33	Allow attachment of one or more clinical facts to Signal, Message or Conditional Start Event.	Indicates data types required to trigger process.

top

3.2.5 Decision Points Sub-Menu Requirements

The following table contains the functional requirements that apply to Gateway decision points:

ID	Description	Scope
3.34	Support decision points.	These gateways are supported: Exclusive: Data-Based Exclusive XOR Gateway Parallel Gateway Inclusive
3.35	Show all outgoing conditions of given gateway connection.	Oryx/Wapama plugin ORYX.Plugins.MouseOverLabelPlugin facilitates this requirement.
3.36	Show condition expression in outgoing connections.	Oryx/Wapama plugin ORYX.Plugins.MouseOverLabelPlugin facilitates this requirement. Show condition expression only when user hovers mouse over object.
3.37	Provide means of specifying conditions of outgoing gateway connections.	Pop-up editor in authoring canvas allows users to choose options from menus without special criteria. No textual entry is required.
3.38	Allow users to define and edit all rules of single gateway at same time.	Drools supports edition of multiple rules at once.

top

3.2.6 Tasks Sub-Menu Requirements

The following table contains the functional requirements that apply to the tasks applied to decision points:

ID

Description

Scope

3.39

Provide task objects appropriate for the creation of discrete logic and complex workflows.

Preliminary task objects include:

Order
Appointment
Email
Page
SMS
Alert
Registration

3.40

Base functional objects exposed to authors in workbench on appropriate standards when available.

top

3.2.7 End Events Sub-Menu Requirements

The following table contains the functional requirements that apply to end events:

ID

Description

Scope

3.41

Provide End Event objects appropriate for the creation of discrete logic and complex workflows.

End Event objects include

End with message
End with signal
Cancel
Terminate: Triggers immediate termination of process instance. All steps still in execution in parallel branches are terminated.
End: Untyped end event typically marks standard end of process.

top

3.2.8 Miscellaneous Sub-Menu Requirements

The following table contains the functional requirements that apply to miscellaneous CDS Palette objects:

ID

Description

Scope

3.42

Provide miscellaneous objects appropriate for creation of discrete logic and complex workflows.

Miscellaneous objects include connector, annotation, and grouping tools used during authoring, as defined by these examples:

Annotation: Any object can be associated with text annotation to provide further documentation.
Group: Arbitrary set of objects can be defined as Group to show that they logically belong together.

top

3.3 Configuration Pane

On the right side of CDS Workbench is the configuration pane where an author can define metadata for the knowledge module as a whole or for each individual component. When the author selects a canvas object, the pane displays the appropriate configuration form. In the case of a Fact object, the configuration pane allows the author to search the included Sirona medical terminologies for the appropriate concept ID that describes precisely what concept the lab template represents. When the author selects a term, a Complete Blood Count for example, the system applies the appropriate terminology code to uniquely identify the fact within the rule syntax. Similar configuration panes uniquely and precisely define each data element used within the knowledge module. System tasks, such as sending an alert or email, also have forms to define the recipient and payload for each task type.

To ensure consistency and complete alignment of the system metadata with the run-time environment, CDS Workbench does not allow the author to enter such metadata by hand. Instead, it relies on metadata look-up tools to prevent an author from accidentally defining a knowledge module that cannot be executed within the run-time environment. CDS Workbench is intentionally a highly constrained application aligned with the operational capabilities of the organization deploying it.

3.3.1 Configuration Pane Display Requirements

The following table describes the functional requirements for displaying the configuration pane:

ID	Description	Scope
3.43	Provide access to attributes and properties of canvas object selected from CDS palette.	Configuration area resides in right-side pane of Workbench user interface, called configuration pane.
3.44	Provide appropriate property fields based on user palette selections.	When user clicks graphical element in canvas, appropriate fields and drop-down menus appear in configuration pane.
3.45	Semantically constrain data elements exposed to authors for building rules.	Allow appropriate terminologies, such as ICD9, SNOMED-CT, LOINC, and CPT, among others.

Unknown macro: {table-plus}

top

3.4 Authoring Canvas

The central authoring canvas occupies the majority of the visible screen. On the central canvas, the author defines the knowledge module workflow and its resulting tasks. Authors connect palette objects dragged onto this canvas to each other to represent the process flow of data. Once the author has defined the required metadata for each palette object, he or she can double-click control objects to define the logical evaluations performed by the knowledge module. In this version of CDS Workbench, only Conditional Start Event and Decision Points are valid control objects.

If the author double-clicks a control object, a rule pop-up editor opens, pre-populated with the Facts that have been connected to the Decision Point or Conditional Start Event. For example, if a clinician selects a chemistry panel as the trigger event that starts a process, double-clicking the conditional start node of the knowledge module allows the author to define the conditional logic that the chemistry panel must satisfy before the rule engine starts the process. The editor displays the various data attributes that a chemistry panel might contain, allowing the author to specify that the rule fires, for example, only when a sodium exceeds a defined threshold. The branching logic of all decision points within the core of the knowledge module workflow description are similarly configured.

The pop-up editor displays only when all Fact Types connected to a control node are fully defined by a corresponding medical terminology code. An error message displays if the configuration is incomplete. When invoked, the editor allows the author to select any attribute represented in the data model and define the logic used to evaluate its value. The Sirona rule engine provides a rich expressive syntax including, but not limited to, standard arithmetic operations and statistical functions.

Fact Types connected to a Conditional Start Event are assumed to be triggering data that the process must evaluate. Facts attached to decision points within the core of the knowledge module are assumed to be historic clinical information retrieved from the Electronic Medical Record; such facts are automatically marked as historic, which by convention cannot trigger a knowledge module or process. The Sirona architecture ensures that a virtual medical record of historic facts is available in memory to the engine so that complex logic of statistical operations are performed in real-time. The rule author may optionally override this default behavior if or when a particular use case requires it.

Selecting the background canvas itself displays metadata pertaining to the knowledge module in the right-side configuration pane. Such metadata may encode the specialty of the author, the goals of the knowledge module, or whether the rule is intended for public sharing or private internal use. Canvas metadata essentially controls module visibility afforded to external organizations, departments, or users. It provides descriptive information that the user may find helpful when searching or evaluating the appropriateness of a particular knowledge module.

The Cohort Object in the CDS palette has special significance if included in a knowledge module. When configured, it provides metadata that defines the operational context in which the rule is designed to operate. Using this object, an author may define the intended age group, whether it is an inpatient or outpatient module, any location constraints, or any other contextual information that defines the targeted environment. Sirona refers to cohort metadata as operational constraints designed to ensure that a syntactically and logically consistent rule is not inadvertently executed in an inappropriate clinical scenario.

CDS Workbench ensures that the clinical rules and workflows described by the author are mapped in a standards-based and semantically consistent way to the technical execution code that the run-time engines require. When the user diagrams a sequence of events best represented as a workflow process, the system automatically ensures that the appropriate BPMN notation is generated to encode the workflow process. Similarly, when an author describes the logic that will be used to evaluate clinical data, the system delivers the appropriate rule engine syntax.

The following figure shows an example of an author design of a process in the central authoring canvas:

Figure 3-2 Example of Process Design in Authoring Canvas

The following figure provides an example of the CDS Workbench pop-up editor that allows the author to set the conditions of a start conditional event, decision points, and constraints on flows.

Figure 3-3 CDS Workbench Pop-up Editor

3.4.1 Authoring Canvas Display Requirements

The authoring canvas reflects workflow considerations and incorporates the logic that controls the process flow of a knowledge module.

The following table describes the functional requirements for displaying rules and workflows in the authoring canvas:

ID	Description	Scope
3.46	Provide canvas space for author to establish workflow of knowledge module.	Canvas resides in center pane of CDS Workbench user interface.
3.47	Provide drag-and-drop function to move palette components onto canvas.	Palette objects are dragged from palette pane and dropped onto authoring canvas.
3.48	Provide means of specifying name of flow.	Single click to flow arrow graphic in canvas while pressing F2 function key displays text box in which user can enter name of flow.
3.49	Provide means of displaying configuration properties for nodes in canvas.	Clicking within node displays node configuration properties in configuration pane.
3.50	Provide workbench facilities for defining dependencies for historic patient information.	This is needed for dependent CDSA evaluations.

Unknown macro: {table-plus}

top

3.4.2 Authoring Canvas Pop-up Editor Requirements

The pop-up editor allows users to define conditions for decision points, start conditional events, and flow constraints. It provides a friendly user interface by which authors can define conditions by selecting Fact types and condition phrases from drop-down menus.

The following table describes the functional requirements for the pop-up editor used to define conditions in the authoring canvas:

ID	Description	Scope
3.51	Provide editor allowing author to define and display required logic for conditional Fact objects and to edit constraints associated with flow.	Pop-up editor appears upon these author actions: 1) Double-click graphical element representing decision point in guideline or Start Conditional Event in canvas. 2) Double-click flow graphics (arrows). Pop-up editor partially obscures workflow in progress in authoring canvas until closed.
3.52	Allow author to express complete logic branching required by guideline.	Green plus sign on right side of pop-up editor allows user to choose from menu of conditions based on model Fact types. User clicks desired condition phrase, then clicks OK. Up and down arrows on right side of pop-up editor window allow user to move up or down condition logic.
3.53	Provide means of deleting entire condition and all its constraints.	Small delete box on condition line provides this functionality.
3.54	Provide means of hiding and displaying condition text.	Toggle box to left of condition name provides this functionality.
3.55	Provide default names for conditions.	If author doesn't specify condition name, pop-up editor provides names in the format Condition n, such as Condition 1.
3.56	Provide means of completing authoring of condition and saving it to workflow in progress on authoring canvas.	Done button provides this functionality. Author returns to more functional representation on authoring canvas after exploring complex logic of guideline or rule.
3.57	Provide means of canceling condition without saving work to workflow in progress on authoring canvas.	Cancel button provides this functionality. Author returns to work in progress on authoring canvas.

top

4.0 Knowledge Module Repository

The Sirona Knowledge Module Repository (KMR) is a database that stores the processes, rules, and knowledge modules created in CDS Workbench. The repository persists and indexes these artifacts, exposing their metadata, text descriptions, clinical contexts, terminology requirements, and other important data so that the user with search privileges can locate them. Search is role based, meaning users can be given the ability to search for all repository artifacts, only those released to production, or only those that the organization has agreed to expose publicly. If artifacts are exposed to the public, Sirona repository search allows a diverse community of medical groups or individuals to share their expertise and standards of excellence with others.

The Sirona KMR provides a type of metadata called categories, which are stored in hierarchical lists. These categories can be considered tags or labels. Category lists, which can be syntactical or semantic, allow users to search the Sirona KMR to find the knowledge module that serves their needs. Semantic tagging will be implemented in a future release.

This section describes the functional requirements governing the management of knowledge modules in the Sirona repository. It also describes the types of metadata, or categories, persisted to the Sirona KMR along with the knowledge module. Other organizations can use this metadata to search for, select, and use the knowledge modules stored in the Sirona repository.

4.1 General Repository Requirements

The following table describes the general functional requirements for the knowledge module repository:

ID	Description	Scope
3.58	Store and index one or more knowledge modules and their assets.
3.59	Ensure workbench can persist all assets into repository.	Assets include processes, rules, and model classes.
3.60	Maintain all previous versions of assets.	Ensures rollback of changes. Provides asset modification history.
3.61	Allow flexible grouping of assets and configuration of assets.	Grouping implemented as packages provides means of separating models, rules, processes, and other assets. Assets in different packages cannot interact, allowing coarse-grained separation.
3.62	Expose required metadata and descriptors.	Metadata includes text descriptions, clinical contexts, terminology requirements, and other important data. Supports distributed service discovery, invocation, and sharing of clinical rules.

top

4.2 Categories Used to Tag Knowledge Modules

The following syntactical categories can be used to tag knowledge modules when they are saved to the Sirona Knowledge Module Repository. Tagging allows users and other organizations to search for and select specific knowledge modules based on syntactic string searches and comparisons. In the future, Sirona will allow semantic tagging and searches based on concept names defined in ontologies.

4.2.1 Knowledge Representation Syntax

The following functional requirements apply to the knowledge representation syntax:

ID

Description

Scope

3.63

Maintain metadata regarding language syntax of knowledge representation.

3.64

Make value set configurable.

Possible values include these, among others:

Narrative Text
Arden Syntax
Decision Tables
GLIF
GELLO
Production Rule

top

4.2.2 Knowledge Terminologies

The following functional requirements apply to the knowledge terminologies allowed in the knowledge module:

ID

Description

Scope

3.65

Maintain metadata on terminologies used within knowledge representation.

Terminologies are stored in MySQL database on system.

3.66

Make value set configurable.

Possible values include these, among others:

ICD9
SNOMED-CT
LOINC
CPT

top

4.2.3 Purpose of Use

The following functional requirements apply to the purpose of use of the knowledge representation:

ID

Description

Scope

3.67

Maintain metadata on purpose of knowledge representation.

3.68

Make value set configurable.

Possible values include these, among others:

Diagnosis
Administrative
Treatment
Notification

top

4.2.4 Narrative Description

The following functional requirements apply to the narrative description of the knowledge representation:

ID

Description

Scope

3.69

Maintain metadata on how knowledge representation works.

3.70

Make value set configurable.

Possible values include these, among others:

How tool works
Parameters incorporated
Logic applied
Samples of result view
How tool is used

top

4.2.5 Tool Type

The following functional requirements apply to the type of knowledge representation tool:

ID

Description

Scope

3.71

Maintain metadata on type of knowledge representation tool.

3.72

Make value set configurable.

Possible values include these, among others:

Manage information
Focus attention
Provide patient-specific recommendations
Alert automatically
Provide calculator
Integrate workflow
Provide order-entry system
Provide scorecard
Evaluate and compare products or services
Monitor adverse drug events
Track
Point to center of excellence or subject matter expert
Manage results (order check, info button)

top

4.2.6 Action Type

In some cases, users need to define action types in their knowledge modules. These action types are stored as metadata in the KMR.

The following functional requirements apply to the action types used in the knowledge representation:

ID

Description

Scope

3.73

Maintain metadata on action types included in knowledge representation.

3.74

Make value set configurable.

Possible values include these, among others:

Orders
Med Alert
Phone Call
Email
SMS
Scheduling

4.2.7 Clinical Venue

The following functional requirements apply to the clinical setting of the knowledge representation:

ID

Description

Scope

3.75

Maintain metadata on clinical setting of knowledge representation.

3.76

Make value set configurable.

Possible values include these, among others:

Acute
Ambulatory outpatient
Emergency
General inpatient
Peri-operative

top

4.2.8 Clinical Specialty

The following functional requirements apply to the clinical specialties associated with the knowledge representation:

ID

Description

Scope

3.77

Maintain metadata on clinical specialties associated with knowledge representation.

3.78

Make value set configurable.

Possible values include these, among others:

All
Hematology and oncology
Pulmonary medicine
Anesthesiology/Peri-operative medicine
Infectious disease
Radiology
Behavioral medicine
Nephrology
Research studies
Burn management

top

4.2.9 Intended Users

The following functional requirements apply to the intended users of the knowledge representation:

ID

Description

Scope

3.79

Maintain metadata on intended users of knowledge representation.

3.80

Make value set configurable.

Possible values include these, among others:

Clinicians
Administrators
Patients
Researcher

top

4.2.10 Hospital Implementations

The following functional requirements apply to the hospital implementations where the knowledge representation is being used:

ID	Description	Scope
3.81	Maintain metadata on hospital implementations associated with knowledge representation.
3.82	Make value set configurable.	Possible values include community ID of facility or organization on NwHIN.

top

4.2.11 Author

The following functional requirements apply to the author of the knowledge representation:

ID

Description

Scope

3.83

Maintain metadata on author of knowledge representation.

3.84

Make value set configurable.

Possible values include

KM Portal
Virtual Diabetes Center

top

4.2.12 Contact Person

The following functional requirements apply to the contact person for questions on the knowledge representation:

ID	Description	Scope
3.85	Maintain metadata on contact person for questions on knowledge representation.
3.86	Make value set configurable.

top

5.0 CDS Workbench Run-time Requirements

When authors create and save their knowledge modules, CDS Workbench compiles the modules for storage, extracts any metadata, and indexes the artifacts. The knowledge module then goes through a quality review process, defined by each organization, which validates the module as safe and appropriate for clinical use. When deployed within the run-time environment, the system can leverage this semantic metadata to locate and retrieve the knowledge modules required to evaluate a patient or cohort of patients. The Quality Assurance program defined by each organization is configured in the Sirona Knowledge Management Administration Portal tool, which helps manage the system during run time. This admin tool also allows configuration of CDS Workbench with facts, tasks, and other objects and ensures that CDS Workbench and the run-time system are well aligned.

The following table describes the functional requirements for the run-time environment:

ID	Description	Scope
3.87	Provide facilities and any required metadata for run-time inference engine.	CDSA can support numerous Clinical Decision Support use cases through one inference engine.
3.88	Provide facilities for defining whether remote nodes have access to local rules for invocation remotely and/or replication.	CDSA provides facilities by which decision nodes on other CDSA hosts can execute rules and workflows remotely. Provide facility to copy rules and workflows to decision nodes on other CDSA hosts.
3.89	Ensure that all rule components are perfectly aligned with semantics and structural requirements of facts that rule engine is evaluating.	Use appropriate terminologies to constrain data elements exposed to author for rule building semantically. Store terminologies separate from knowledge module repository.
3.90	Ensure that logical operations resolve with highest degree of precision.	At deployment within run-time environment, CDSA evaluates data with matching concept ID. Sirona leverages metadata stored in repository for precision. CDS Workbench provides facilities for incorporating core logical operations.
3.91	Provide facilities for defining operational metadata or medical equipment, reference ranges, services, and required data elements.	Operational constraints are required for predictable execution of valid distributed rules within variety of organizations.
3.92	Provide facilities for BPMN2 mapping and extension.	BPMN2 is convenient base syntax. Customized extensions support more fine-grained constraints and branching logic. Customizations are driven by use cases.
3.93	Provide facilities for cross-compiling internal syntax of decision node definitions into executable form required by operational environment.	To ensure definitions for particular clinical evaluation (decision point) can be shared between different workbenches, CDSA provides terminology translation services to cross walk between CDS Workbench terminologies used to create idealized evaluation and those used by run-time host information.
3.94	Provide facilities for defining execution priority.	CDSA ensures quality-of-service contracts for processing high-value trigger messages from work queue, ensuring high-risk patient data are evaluated first if backlog exists. Traditional first-in, first-out processing applies if multiple triggers with same priority exist. One typical example of prioritizing is to process inpatient triggers before outpatient ones. Use scope of rules to prioritize rule execution and notification message delivery.

top

Browser not supported