In this paper, we propose an approach for specication and analysis of Computer-Interpretable Clinical Guidelines (CIGs) that was inspired by Behaviour-Driven Development. The expected behaviour of a CIG is specied by requirements in natural language. On the one hand, those requirements are used as design input for guideline development. On the other hand, they can be checked against time-oriented data recorded during testing sessions of the implemented CIG.
Behaviour-Driven Development (BDD) is an agile Software Engineering (SE) methodology, that conforms to the Test-First principle: Test cases are developed previous to the software system itself. In BDD, executable test cases are directly derived from requirements stated in natural language, by employing a pattern matching approach. This enables stakeholders to actively participate in the denition of requirements, which are a fundamental design input for the system under development.
In contrast to other Test-First approaches (like Test-Driven Development), BDD focuses on the creation of acceptance tests rather than unit tests. The former ones assure the acceptance of the system by its users, as the system’s ability to fulll their needs with respect to a business value is tested. The latter ones perform testing on a lower system level by checking individual program constructs. This has the potential to reduce the number of defects at an early stage of the software development process.
Scenario : t r a d e r i s not a l e r t e d below t h r e s h o l d
Given a s t o c k o f symbol STK1 a t a t h r e s h o l d o f 1 0 . 0 When t h e s t o c k i s t r a d e d a t 5 . 0
Then t h e a l e r t s t a t u s s h o u l d be OFF Scenario : t r a d e r i s a l e r t e d above t h r e s h o l d
Given a s t o c k o f symbol STK1 a t a t h r e s h o l d o f 1 0 . 0 When t h e s t o c k i s t r a d e d a t 1 1 . 0
Then t h e a l e r t s t a t u s s h o u l d be ON
BDD frameworks exist for several programming languages, e.g. JBehave 3
(Java) or RSpec [
The keyword GIVEN sets up the test environment by creating the specic context which is necessary to execute the test.
Second, the functionality under test is executed (keyword WHEN). Lastly, the outcome of the previous step is compared against the expected one (keyword THEN).
Each group can contain several steps that are joined together using the keyword AND. Each step in turn, is backed by a step template (also called support code ), that converts the text into executable program code using regular expressions, e.g. to extract method parameters. Figure 2 shows the step templates needed to execute both scenarios shown in Figure 1.
As each step is individually backed by support code, steps can arbitrarily be combined to create new acceptance tests. Thanks to the comprehensibility of Gherkin and the use of natural language, scenarios can easily be created also 3 http://jbehave.org p u b l i c c l a s s T r a d e r S t e p s { p r i v a t e Stock s t o c k ; @Given ( "a s t o c k o f symbol $sym at a t h r e s h o l d o f $ t h r " ) p u b l i c v o i d aStock ( S t r i n g sym , double t h r ) {
s t o c k = new Stock ( sym , t h r ) ; } @When( " the s t o c k i s t r a d e d at $ p r i c e " ) p u b l i c v o i d theStockIsTradedAt ( double p r i c e ) {
s t o c k . tradeAt ( p r i c e ) ; } @Then( " the a l e r t s t a t u s s h o u l d be $ s t a t " ) p u b l i c v o i d t h e A l e r t S t a t u s S h o u l d B e ( S t r i n g s t a t ) {
ensureThat ( s t o c k . g e t S t a t u s ( ) . name ( ) , equalTo ( s t a t ) ) ; }
}
by non-programmers, e.g. the future users of the software themselves. That way,
a ubiquitous language [
In the remainder of this section, we describe an approach for the specication of automated CIGs following the BDD methodology. The CIG behaviour is specied as a set of scenarios expressed in the Gherkin language:
The GIVEN group of a scenario describes the precondition in terms of the patient’s current state, and possibly also its past progression.
The expected therapeutic action, i.e. the output of the CIG for the given patient state, is expressed in the WHEN part of the scenario.
The THEN group contains assumptions about the future (improved) patient state, based on the therapeutic action. As the eects will take some time until they are measurable, usually a temporal annotation is included.
There is a main dierence between the SE acceptance tests as described in the previous section and the CIG scenarios. While the former ones are actively preparing the test context and executing the function under test, the latter ones can only passively be evaluated on data a patient delivered. The CIG scenarios are interpretable descriptions of patterns that are supposed to occur in patient data, given that the CIG has correctly been implemented based on an error-free specication.
After implementing the CIG based on the dened scenarios, test cases can be
recorded, e.g. using a patient simulator [
We have implemented an extension for the Semantic Wiki KnowWE that
supports the described approach. Each step template consists of a regular expression
containing capturing groups enriched by a type system, and a formal condition
with the according placeholders. When using step templates, the placeholders are
lled with terms from a predened ontology, that contains the data denitions
of the CIG (cf. Figure 3, left side). The ontology is created as the foundation for
the fully formalized CIG [
The results of the scenario analysis with respect to a test case are visualized on an interactive timeline, that can be panned and zoomed, cf. Figure 4. Each band corresponds to exactly one scenario. At each instant of time, an icon represents the result, if the scenario’s precondition is fullled: omitted therapeutic action (red warning sign), unfullled postcondition (yellow warning sign), and fully satised scenario (green checkmark), respectively. The timeline is integrated into KnowWE’s testing framework. Replaying the test case to any instant in time is possible to introspect CIG execution for debugging purposes.
For the evaluation of the presented approach, we are currently working on a
case study with a real world CIG and patient data from a previous study
conducted at the Department of Anesthesiology and Intensive Care Medicine,
University Medical Center Schleswig-Holstein, Campus Kiel [
This study does not investigate the usage of the derived specication as a design input. It focuses on the applicability of the approach in terms of usability and expressiveness, and its usage for analysing the test cases regarding the scenarios. The CIG behaviour has been specied using natural language scenarios as described herein. By exploiting strict naming conventions regarding the labeling of related data, e.g. measurements and their corresponding upper and lower limits, only a rather limited set of about 15 step templates needed to be dened. This allows for fast requirements elicitation and also reduces maintenance eorts. 5
In this paper, we have described an approach inspired by Behaviour-Driven Development for specication and analysis of Computer-Interpretable Clinical Guidelines. Requirements stated by medical experts in natural language are used as design input for the development of CIGs and their analysis using test cases. We demonstrated the applicability of Behaviour-Driven Development for CIGs using an extension for the Semantic Wiki KnowWE. Currently, we are conducting a case study focusing on the analysis aspect. A real world CIG and test cases from a real patient study are used for evaluation. So far, the approach has shown its applicability in terms of usability and expressiveness. In the near future, the results of the scenarios will be analysed by medical experts.