This is an open-access article distributed under the terms of the Creative Commons Attribution License (https://creativecommons.org/licenses/by/4.0/), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work, first published in JMIR Formative Research, is properly cited. The complete bibliographic information, a link to the original publication on http://formative.jmir.org, as well as this copyright and license information must be included.
Displeasure with the functionality of clinical decision support systems (CDSSs) is considered the primary challenge in CDSS development. A major difficulty in CDSS design is matching the functionality to the desired and actual clinical workflow. Computer-interpretable guidelines (CIGs) are used to formalize medical knowledge in clinical practice guidelines (CPGs) in a computable language. However, existing CIG frameworks require a specific interpreter for each CIG language, hindering the ease of implementation and interoperability.
This paper aims to describe a different approach to the representation of clinical knowledge and data. We intended to change the clinician’s perception of a CDSS with sufficient expressivity of the representation while maintaining a small communication and software footprint for both a web application and a mobile app. This approach was originally intended to create a readable and minimal syntax for a web CDSS and future mobile app for antenatal care guidelines with improved human-computer interaction and enhanced usability by aligning the system behavior with clinical workflow.
We designed and implemented an architecture design for our CDSS, which uses the model-view-controller (MVC) architecture and a knowledge engine in the MVC architecture based on XML. The knowledge engine design also integrated the requirement of matching clinical care workflow that was desired in the CDSS. For this component of the design task, we used a work ontology analysis of the CPGs for antenatal care in our particular target clinical settings.
In comparison to other common CIGs used for CDSSs, our XML approach can be used to take advantage of the flexible format of XML to facilitate the electronic sharing of structured data. More importantly, we can take advantage of its flexibility to standardize CIG structure design in a low-level specification language that is ubiquitous, universal, computationally efficient, integrable with web technologies, and human readable.
Our knowledge representation framework incorporates fundamental elements of other CIGs used in CDSSs in medicine and proved adequate to encode a number of antenatal health care CPGs and their associated clinical workflows. The framework appears general enough to be used with other CPGs in medicine. XML proved to be a language expressive enough to describe planning problems in a computable form and restrictive and expressive enough to implement in a clinical system. It can also be effective for mobile apps, where intermittent communication requires a small footprint and an autonomous app. This approach can be used to incorporate overlapping capabilities of more specialized CIGs in medicine.
With the increasing adoption of electronic health records and hospital information systems, the implementation of clinical practice guidelines (CPGs) through integration with these information systems is possible during clinical encounters [
A CDSS produces patient-specific output based on patient data combined with these representations of medical knowledge [
There have been widespread reports of dissatisfaction and user complaints with existing CDSS functionality, and satisfaction is considered one of the primary challenges for improving CDSS development and acceptance [
In a CDSS, computer-interpretable guidelines (CIGs) are used to formalize medical knowledge contained in CPGs into a computable form. Additionally, we can create a set of software functions for the CDSS user interactions that also match the clinical workflow [
We considered several different representation languages for our CDSS system. One approach we considered was to use an existing CIG syntax, such as Arden syntax or Guideline Interchange Format, to represent the medical knowledge found in the CPG. However, we decided to develop our own syntax to handle clinical data and knowledge because we are aiming to implement our CDSS with a model-view-controller (MVC) architecture appropriate for both web applications and mobile apps. We intended to repurpose the CIG knowledge engine core and the represented medical content for mobile app development. We had the additional goal of ensuring that the executable representation be human readable and have sufficient but minimal syntax and process elements for our particular CPGs. Importantly, we took a minimal design approach, in that we wanted the footprint of the software to have as small a computational and data footprint as possible, since we intended to use the resulting tools both in a web application and mobile app. In our environment, the mobile app may not have continuous connectivity to the networked computing resources, requiring it to execute autonomously if necessary.
With these requirements in mind, we chose XML as a better language to represent CPG knowledge. For web applications and mobile apps, this is an ideal choice as a core component of the World Wide Web. XML is key to formatting content into HTML pages and is an industry standard for data communication among different computer systems [
There is increasing interest in software frameworks and the feasibility of representing knowledge such as CPGs in semantic web technologies [
There are many other challenges to CDSSs in the environments in which we are implementing our system. There are issues of scale in the management of guidelines in CIG forms, history tracking, CIG version control, and automatic aggregation of CIGs. In this paper, we focus on a narrow subset of such desirable requirements. We are only concerned with having sufficient expressivity of the representation while maintaining a small communication and software footprint for mobile apps that can also be repurposed without modification for incorporation into web applications and other mobile apps. To our knowledge, none of the approaches taken above would be satisfactory for those requirements. In the future, as our approach develops, we will also address these other important issues and be in a better place to compare our approach on those dimensions. In this paper, we focus on the adequacy of satisfying the requirements for expressivity and minimal communication and computing resources.
In
Architecture design used in the web-based clinical decision support system.
First, the model consists mainly of a database system used to store the patient's phenotypic and laboratory data so the database can be queried when required [
Second, the view refers to the system components the user interacts with that display in the user interface.
Third, the controller refers to the system components responsible for processing queries and the user’s interactions. The controllers pass patient input data to the computable guideline model, which is used to query the database, and then select a view to display for the user interface [
Fourth, the knowledge engine is the CIG where the decision-making rules capturing the CPGs are stored and where the knowledge for integrating the clinical health care workflow and CPGs are stored and interpreted.
In this paper, we exclusively present the design of the knowledge engine, a collection of XML documents and an associated interpreter to handle clinical data and encoded knowledge. The relation between the functionality of the CIG subsystem and the MVC architecture involves the knowledge engine driving the controller’s functionality, alongside a graphic representation of the views. We analyzed some CIG syntaxes in order to find common and minimal features for knowledge representation to incorporate in our XML. We particularly wanted to have design control of features directing user attention to system outputs and improve system usability by being able to match the standard workflow of the clinical situation.
For the CDSS knowledge engine, we adopted state machines, artificial intelligence (AI) planning techniques and methods, and minimal CIG functionality. We now briefly describe our decision-making process for each of these.
There are many ways to computationally model knowledge and behavior in AI systems, and the use of state machines is one of the oldest and best known [
In AI, a plan is generally defined as a sequence of actions that will achieve a specific state. A state refers to the multiple logical conditions that are true in a certain situation, or what could be also known as the “state of the world” [
Computer-interpretable guideline formalisms comparison.
Detail | Arden syntax |
GLIFa |
PROforma |
Asbru |
Eon |
Model | Medical logic module | Object-oriented flowchart structured in steps | PROforma task ontology | Plan | Dharma guideline model |
Model elements | Maintenance, knowledge, library, resources | Branch, decision, action, patient state steps | Plans, decisions, actions, inquiries | Preferences, intentions, conditions, effects | Scenarios, decisions, actions, activities |
Language | - MLMsb are text based (each MLM is encoded as an ASCIIc file) | - UMLd class diagrams in GLIF3 XML-based syntax |
- Guidelines are translated into language called LR2L |
- DTDf in Backus-Naur form |
RDF |
aGLIF: Guideline Interchange Format.
bMLM: medical logic module.
cASCII: American Standard Code for Information Interchange.
dUML: Unified Modeling Language.
eRDF: Resource Description Framework.
fDTD: document type definition.
In designing a minimal-specification XML file to manage clinical data and knowledge for a web-based and mobile CDSS for antenatal care, we compared and analyzed some CIG approaches found in OpenClinical [
The knowledge engine design also integrated the requirement of matching care workflow that was desired in the CDSS. Here we used a work ontology analysis [
We then used Microsoft Visual Studio (Microsoft Corp) to develop an XML Schema Definition (XSD) to ease the knowledge-encoding process into rule statements. Lastly, we compared our XML document file with an Arden syntax file that we coded doing a similar task in the interest of comparing our representations with one of the CDSS standards often used to manage and apply clinical knowledge in health care settings.
As discussed in de Clercq et al [
Ontology knowledge structure extraction for antenatal clinical practice guidelines.
Main actions | Health care provider action | Goal | Precondition | Action |
Observation | Examination findings, family history, lifestyle factors, health summary, pregnancy summary, nutrition summary, physical activity summary, social summary, laboratory test, reason for encounter | Record observation and information about the patient | Information is missing or incomplete | Request information |
Evaluation | Absence of information, clinical synopsis, adverse reaction risk, health risk assessment, problem/diagnosis | Analyze information and absences of information | Information is in database | Compare information, risk assessment |
Action | Care plan, health education, medication order, laboratory test request, procedure request, notification | Suggest a proper care plan and notify health care provider of an event | Evaluation is done | Suggest medication order, laboratory test, or procedure; generate a notification, alert, or message |
At the next level of system design, we used XML-encoded rules to represent the state transitions of a state machine. This state machine protocol file is the core component for future proposed implementations of CDSS content captured in a state machine and interpreted as state machine behavior.
The CDSS uses XML logical methods to interpret data entries through conditional rules to achieve representations of goals and actions. The XML interpreter will usually execute the logic through a match-and-resolve process. First, all rules with conditions corresponding with the input data are evaluated, and if the conditions are satisfied, the rules will execute.
In the pseudocode of
Pseudocode for our knowledge representation.
The rule sets are arranged in a hierarchical structure to capture basic AI planning concepts; inner rules will only evaluate if outer rules in the hierarchy are true. Nodes are aggregates of conditions, which are sets of data as well as a set of rules. Each XML node also has a goal representation, a precondition representation, and an action representation. An XML node corresponds to a basic AI planner module. After the execution of the actions, there will be an update of the representation in terms of state representations, as seen in the pseudocode.
Nodes are the containers where a particular set of goals are established; this is used to give a structure and readability to the XML file.
Goals are considered the main representational purpose for the node to achieve, and when the representation conditions are accomplished, the node will be considered complete and will no longer be able to execute. This is so the system will not compute statements for an undefined period of time. For each of the conditions or rules inside the goal representations and precondition representations, we declare a Boolean expression with the logical operator or operators, including the set operation, in a set as well as in range. Inside each Boolean expression, we reference a represented semantic path to a symbol to access the required values of concept representations that can be related to a specific ID in the database.
Preconditions are the statements that are required to be satisfied before a rule triggers the execution of the associated rule action. Even if the rule inside the goal satisfies the conditions, the action will not be executed. In our knowledge representation, actions can be triggered in 4 different ways: (1) the passage of time; (2) the entry of a data pattern for a patient’s symptom, problem, or diagnosis; (3) the entry of a representation of a diagnostic test value; and (4) the entry of a representation of a treatment result.
Actions are the representation’s output based on specific input conditions, which in turn are based on the rule by which goals and preconditions are satisfied. The actions that are applicable to a state are all those whose preconditions are satisfied. An action means there is a transition between states for the state machine, meaning that certain medical conditions were satisfied in the goal and precondition nodes. An action might be a new request for data, a message, a medical alert, a medical recommendation, or even a calculation, depending on the situation. At this point, it is important to make it clear that when an action takes place, the conditions in the goal will be completed. Otherwise, the node will execute every time the system evaluates the conditions.
The result of our knowledge representation is written and stored in an XML file. XML-encoded rules represent state transitions of the state machine system. This XML file and associated interpreter will be the inference engine core for any expanded future CDSS CIGs with state machine behavior in our future designs.
An XSD schema file was designed with the intention to ease the creation of the XML representations of CPGs with the medical knowledge representation proposed. In
First, the Boolean expression can be any of the logical operators: “and”, “or”, or “not”. It may also be any of the comparison operators: equal to, greater than, less than, not equal to, greater than or equal to, or less than or equal to. It can be true or false. It also includes the set operations “in-set” and “in-range.”
Second, a symbol is just a string representation of a variable.
Third, a value is the different “values” that symbols can take.
Fourth, the InSet type represents whether a particular symbol is in the set of values. The set can either be empty or infinite.
Fifth, the Paren type represents a parenthesized expression. It contains both the opening and closing parentheses and the expression within the parentheses.
To demonstrate the proposed knowledge representation, we will now show the code of an XML example for the medical situation of choosing a treatment when bacteria are present in the urine. In our example, knowledge is used to suggest a treatment when bacteria are present and their presence is captured in the record. The goal of our example is a patient free of bacteria in the urine. When this is conceptualized as a state machine system, the goal will be achieved by a state machine node representing the patient no longer having the bacteria present in the urine. Our preconditions will be satisfied and rules will be triggered by the colony-forming unit (CFU) value found in a previous urine culture test. There can be multiple kinds of potential actions. We want to address two common actions, a drug order for treatment according to the CFU count and an alert to the physician to determine if there remain bacteria in the urine.
If the patient’s health improves but the lab result indicates there is still the presence of bacteria in the urine, but with a lower CFU, the system should evaluate the conditions and suggest a different treatment more matched to the patient conditions. The goal will still be the same, since the presence of the bacteria is still positive, but the preconditions (trigger) and the actions will be different.
For illustrative purposes,
XML Schema Definition file schema.
In
Our plans involve the computerization of antenatal health care guidelines with our knowledge representation for a web-based CDSS, and then a mobile app. The clinical decisions suggested will assist clinicians in three situations. First, it will evaluate obstetrical risk and inform clinicians and raise health alerts about patients’ medical conditions, like pre-eclampsia, diabetes, or premature birth. Second, it will suggest medical procedures and drugs according to the gestational age of the mother and her clinical condition. Third, it will make referral suggestions for transferring patients from primary to secondary care and vice versa.
As discussed in the Introduction, our knowledge representation was designed for an antenatal care CDSS project with requirements for both a web and mobile CDSS but also designed to be usable for many other purposes as part of future implementations of other clinical applications. Future applications will test the adequacy of the framework to support additional information and workflow needs of CPGs for other health services and allow us to expand the framework as needed.
For our particular antenatal domain problem scenarios, we found our current framework and implementation methods adequate to capture the workflow and decision logic of the existing guidelines (
It is possible to accommodate either controlled vocabulary terms from standardized sources in the XML representation or ad hoc terms. We anticipate that controlled vocabulary terms will be needed for more complex systems for interoperability with other care systems or to accommodate a greater variety of users than our current system allows. Standardized terms would also result in a more understandable human-computer interface. In more complex systems, there is often a need to include common terms for the purpose of human and machine reference and communication, but with minimal addition, the current approach appears to accommodate any Arden syntax medical logic module representation.
The task modeling ontology we chose was also adequate for our current system and easily represented in XML. The elements of the state machine process representation for the system’s problem-solving steps that achieve a task goal and decompose tasks into subtasks were adequate for the antenatal system. A stochastic process representation addition is anticipated for other domains but can be accompanied within a stochastic state machine framework. The rule representation used also proved adequate for capturing the performance of Arden syntax MLMs.
An important step to consider in future projects will be parsing existing Arden syntax MLMs to our representations, since Arden syntax is an official and commonly used standard and there are plenty of MLMs with encoded medical knowledge using it. Certainly, at its current stage of development, our approach is not able to capture the more sophisticated logic required by the axioms using semantic web rules, such as Semantic Web Rule Language [
We have sacrificed generality in the representation to achieve a minimal design footprint and execution efficiency across multiple computing environments while adequately capturing the guidelines required for our project. It is possible to think of the current representation as a compiled or low-level interpreted version of a more complex representation of guidelines that retains the computation resource efficiency and probability of the current approach for both web applications and mobile apps. In that case, an associated higher-level representation allowing for more generality and a friendlier user development environment based on the more complex representations would be possible.
In the future, having an interface design tool for authoring and editing our XML-represented protocols will be useful to ease the encoding of knowledge. XML is not hard to understand once people get used to it, but this does not mean that there cannot be another tool to encode medical knowledge more easily with XML. A graphic user interface that is object oriented can likely be designed to help the encoding process for health care professionals, who are more motivated than computer engineers to participate in encoding medical knowledge.
Usability of a CDSS depends heavily on the match of system flow to health care workflow. Allowing for consistent stepwise processing of health data over time can support adherence to best clinical practice. Consistent with best-practice CPGs, the intent of the CDSS is to reduce the caregiver’s mental load and prevent possible errors in clinical tasks that involve the analysis of a patient’s status and the use of this context for action decisions. Our knowledge representation framework incorporates fundamental elements of other CIGs used in CDSSs in medicine to encode a number of antenatal health care CPGs and associated clinical workflows. The framework appears general enough to be useful with other CPG-to-CIG projects in medicine.
XML proved to be a language expressive enough to describe the planning problems in a computable form and both restrictive and expressive enough to implement in a clinical system. It can be effective for mobile apps, where intermittent communication requires a small-footprint autonomous app. It can be used to incorporate overlapping capabilities of more specialized CIGs in medicine. These qualities of the XML language give it viability for use in CDSSs as a knowledge engine core that is based on a widely available and understood collection of technologies for web applications and mobile apps.
Example: comparison between Arden syntax and our XML file in starting antibiotic treatment.
artificial intelligence
clinical decision support system
colony-forming unit
computer-interpretable guidelines
clinical practice guideline
fuzzy cognitive map
medical logic module
model-view-controller
XML Schema Definition
This work was supported by Departamento Nacional de Planeación through the Desarrollo de Soluciones en CTi para Telesalud en el Departamento de Antioquia project.
None declared.