Requirements - Clinical Decision Support Workbench

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:

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.

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:

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:

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:

top

3.2.2 General Palette Object Requirements

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

top

3.2.3 Start Events Sub-Menu Requirements

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

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:

top

3.2.5 Decision Points Sub-Menu Requirements

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

top

3.2.6 Tasks Sub-Menu Requirements

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

top

3.2.7 End Events Sub-Menu Requirements

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

top

3.2.8 Miscellaneous Sub-Menu Requirements

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

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:

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:

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:

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:

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:

top

4.2.2 Knowledge Terminologies

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

top

4.2.3 Purpose of Use

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

top

4.2.4 Narrative Description

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

top

4.2.5 Tool Type

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

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:

4.2.7 Clinical Venue

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

top

4.2.8 Clinical Specialty

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

top

4.2.9 Intended Users

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

top

4.2.10 Hospital Implementations

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

top

4.2.11 Author

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

top

4.2.12 Contact Person

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

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:

top