A Prototype of a Decision Support System for Equine Cardiovascular Diseases Diagnosis and Management

: Proper diagnosis and management of equine cardiac diseases require a broad experience and a specialization in the ﬁeld, but acquisition of speciﬁc knowledge is difﬁcult, due, among other reasons, to the limited literature in this ﬁeld. Therefore, we have designed, developed, and implemented (on a computer algebra system) a Decision Support System (DSS) for equine cardiovascular diseases diagnosis and management based on clinical practise. At this step it is appropriate for equine science teaching, but this work paves the way for a clinical decision support system that facilitated equine clinicians the management of horses with cardiac diseases, allowing improving health care in this species. The latter would require extensive testing prior to its use. The novelty of this work relies on the organization of the equine cardiology workﬂow in mathematical logic form, that allowed designing, develop and implement a DSS in this new ﬁeld. An innovation of this work is the part of the DSS devoted to data completion (motivated by the possible lack of specialization of the users—the veterinarians).


Equine Cardiovascular Diseases
Heart murmurs and arrhythmias are commonly identified in riding horses [1,2]. Most horses with cardiac disease have a useful performance life, but they can occasionally develop clinical signs that vary from slightly altered clinical signs to poor performance, exercise intolerance, weakness and collapse, among others [1,3] Horses may suffer from physiologic murmurs and benign arrhythmias, and distinguishing those caused by cardiac abnormalities may be difficult [4], unless the veterinarian is a clinician veterinarian specialized in equine cardiology. In addition, guidelines in cardiovascular diseases and literature regarding prognosis and outcome of horses with cardiac disease are scarce [1]. Thus, an important challenge for the general equine clinician is to establish whether a cardiopathy has no clinical relevance or, conversely, it has an impact on the horse's performance and life expectancy or on the horse's and rider's safety [1]. This latter point is very important as horses collapsing during exercise may suffer catastrophic lesions and up to 22.8% of riders were injured during these episodes and while riding a horse that presented sudden death ( Figure 1) [5]. Therefore, appropriately clinical management of heart disease in riding horses may be imperative, not only for increasing the horse's life-expectancy, but also for human safety concerns. Low quality photogram of a real life video of a horse with an atrial fibrillation collapsing during exercise. We are used to seeing scenes of horses falling to the ground in Western films, but they are not real. The great value of this image is that an amateur video captured the precise moment when the poor horse unexpectedly collapses (its head is very low) and the rider (whose legs are clearly visible and is going to be thrown over the horse's head). We include the image here despite its low quality because we consider it a real document illustrating the dangers of a horse collapsing during exercise.

On the Need for Such a Tool
Diagnosis in the veterinary field is probably even more challenging than in medicine for two reasons: veterinarians usually deal with a variety of species and their patients, although very smart, cannot report their symptoms.
Moreover, veterinarian are usually specialized in the most common domestic animals, but, in many cases, a specialist in specific disorders of a certain species is needed.
Actually, even veterinarians specialized in horses usually lack deep training to properly address cardiovascular diseases in this species. Similarly, in the case of human beings, if a General Practitioner detects a patient with a cardiopathy, he/she refers the patient to the cardiologist. After evaluation, the cardiologist could ask for further tests, such as echocardiography, resting/exercise electrocardiography, etc. The same holds for horses (Figures 2 and 3).  Although there are general works in the field of equine diagnosis, such as [6], we know of no one specialized in equine cardiovascular diseases. Reference [6] is an equine general disease diagnosis expert system that was developed using an ontology system that uses the clinical signs as input. It is capable of reliably diagnosing 40 of the most common equine diseases. However, cardiac alterations are not common in this specie and this ontology system merely addresses heart failure (without going into detail).
We consider that such a DSS would be very useful for the many non-specialized veterinarians that have to deal with horses from time to time.

Some Generalities about Decision Support Systems
DSS are information systems that support decision-making [7,8]. One kind of DSS are knowledge-driven DSS (based on the use of a Knowledge Based System -KBS).
A very common type of KBS are Rule Based Expert Systems (RBES), where the expertise is stored as facts, rules and integrity constraints. RBES do not use conventional programming: they reason through bodies of knowledge, using IF THEN rules that are fired when the variables in their antecedent hold (observe that rule firing concatenates as many rules as necessary). The underlying logic in RBES is not restricted to classic Boolean logic.

Different Approaches to DSS in Previous Works of the Authors
In the past, we used different approaches for knowledge extraction and verification of RBES in which the underlying logic is either classic Boolean logic or many-valued modal logic, and the similar problem of decision making in a railway interlocking system:

•
Gröbner bases-based approach to RBES: a polynomial Boolean ring (a residue class ring), that can be obtained from a polynomial Boolean algebra that is isomorphic to the propositional Boolean algebra translating the logical knowledge in the RBES is used. Knowledge extraction in the RBES is translated in terms of (polynomial) normal forms while the formal verification of the RBES is translated in terms of the degeneracy of the residue class ring into {0} (what can be checked using Gröbner bases). This approach is very well suited to address RBES in which the underlying logic is many-valued modal -with a prime number if truth values) [9] and has been used in different diagnostic systems in medicine such as in [10]. • Decision making in railway interlocking systems using Gröbner bases: this topology independent approach evaluates a proposed situation of the trains and the switches of the turnouts and the indication of the colour-light signals, which is translated into the reflexive-transitive closure of a digraph, itself interpreted as a polynomial ideal. That this polynomial ideal is not the whole polynomial ring is proven to be equivalent to the safeness of the proposed situation. It was implemented in the Computer Algebra System (CAS) Maple (Maple is a trademark of Waterloo Maple Inc. ) [11]. • The same problem, interpreting the digraph from a logic point of view was treated in [12] (the implementation is written in Maple too). • Finally, a similar approach to decision making in a railway interlocking using answer set programming (the notion of answer set [13] is an extension of the notion of stable model [14]) was implemented in Smodels [15][16][17] and is detailed in [18].
There are recent innovative approaches in the line of research of algebraization of logic and RBES such as [19,20].

Generalities about This Equine Cardiology Decision Support System
The two authors decided to collaborate to design, develop and implement a prototype of a DSS about equine cardiovascular diseases. It should address both the diagnosis and the management of the horse.
We wanted the DSS to both easily guide a veterinarian through the different steps of the complex diagnostic procedure (that sometimes requires several tests) and to make a final diagnosis together with recommendations about the horse's management (derived from its health state valuation).
The cardiological knowledge underlying the proposed system was selected and synthesized by the first author. The sources were her experience (consider, for instance [21][22][23]) and specialized literature such as the already mentioned [1][2][3][4][5][6]. This knowledge was translated into logic expressions in collaboration with the second author, which is also responsible for the implementation. Observe that no study involving animals has been carried out to develop this prototype.
As the data available are not always exhaustive in medicine and veterinary medicine, we thought about using a three-valued logic. The main candidates were Łukasiewicz's and Kleene's. Summarizing, in both of them a third truth value is considered ("indeterminate"/"undefined") and their main difference is the truth value of "implies" for this third truth value. This difference is derived from considering that either the third truth value is "indeterminate", i.e., it could take any of the values true or false (but which one is presently unknown), or that this third truth value consists of a real third "undefined" possibility. The use of these sort of truth values is especially interesting in medical and veterinarian DSS for beginning extracting knowledge meanwhile the results of a test are not yet known.
Nevertheless, our DSS is aimed at a user that is a veterinarian not specialized in equine cardiology and we wanted to go one step further, not only extracting knowledge in the case of indetermination, but even guiding the user in the tests to be carried out.
Therefore we decided to organize the DSS in two separate parts: • A "normal" RBES whose underlying logic is classic Boolean logic that extracts knowledge (partial conclusions or diagnoses and the need to new tests to be carried out).
Observe that the DSS asks for new tests to be carried out (while necessary, which can happen more than once) and it does not provide a diagnosis unless the situation is clear. Therefore there is no need to adopt other more computationally expensive logics such as many-valued modal logic or fuzzy logic). • A complementary set of procedures that, in the case of data incompleteness, that is, in case the user has not informed the system whether certain variables in the antecedent of the rules are stated as true or false, asks the unaware user to provide this information. We believe that this tailor-made complement is very useful and we know of no similar one. Unfortunately this approach is laborious.
This new computer tool could be classified as a a RBES which underlying logic is classic Boolean, completed with a data completion system.
We have used for this first prototype the Logic package provided by the CAS [24] Maple 2021 [25][26][27][28][29][30], resulting in a brief, simple and fast implementation. It uses the connectives provided by its specialized Logic package: &and, &or, &not, &xor, &implies as well as he command Implies that tests the logical implication specified. Please note that these logical operators designed to build propositional formulae and perform computations in logic. They are different from the usual Maple programming language operators and, or, not, xor, and implies used in conditional statements (in Maple the underlying logic is three-valued, as a third FAIL truth value is considered, meanwhile the logic used by the Logic package is classic Boolean logic).
In this case, with a few dozen rules, the implementation returns the answers to both issues in 3-4 s on a standard portable computer. Nevertheless, we will also consider different approaches in the future.
All input data have to be typed by the end user. Some can be judged by a general veterinarian (such as whether the horse has a "high heart rate" or not) while others (such as interpreting some details of the electrocardiogram) may require the help of an equine cardiologist. Let us underline that the DSS does not try to substitute the equine cardiologist, but to help a general equine veterinarian in assessing the severity of the disease. It could also be used by an equine cardiologist that would like to have a second opinion.
The whole process has taken a long time. A preliminary version of the work was already presented at the ESCO 2020 conference.
From the academic point of view the system has two innovative aspects: the data completion part and its topic (equine cardiology). It has two possible uses: teaching, and real clinical practice (the latter once extensively tested and approved -for obvious reasons).

Details of the New Decision Support System Designed and Developed
The DSS system is split into five subsystems: • Previous Definitions Subsystem • Subsystem I (first level input data and conclusions/ask for more data) • Subsystem II (second level input data and conclusions/ask for more data) • Subsystem III (diagnoses): IIIa: arrhythmias/IIIb: murmurs (third level input data and conclusions/ask for more data) • Subsystem IV (management).

Processes
As said above, two different kinds of processes are carried out at each subsystem: (i) Knowledge extraction: the DSS obtains conclusions from the input data introduced by the end user by forward firing (it can be understood as a standard RBES knowledge extraction). For instance, if from the expert's knowledge we have that p ∧ q → u and the user has stated p and q as true (or they have been obtained by forward firing of other rules), the system deduces u, where u is usually (a) a partial conclusion or partial diagnosis but can also be (b) the need to perform a test.
(ii) Data completion: the DSS checks if more data should have been introduced in order to reach the next partial or final diagnosis. It should not be confused with the DSS asking for further tests (after performing the knowledge extraction) mentioned in (i)(b). Here the system checks if the end user has not introduced all the needed data and asks which input data to complete. It can be due to two reasons: (c) The DSS has performed some knowledge extraction and, with the new information, more data have to been given to the system to correctly continue performing the knowledge extraction. (d) An unaware end user has not introduced all the data of a certain step of the process.
For example, if from the expert's knowledge we have the rule p ∧ q ∧ r ∧ s → u and the user has stated p and q as true (or they have been obtained by forward firing of previous rules) but has said nothing about r and s, the DSS will ask him/her to declare whether r and s are true or false. If both of them are true, the rule will be fired (that is, u will be reached), otherwise it will not be fired (that is, u will not be reached as a conclusion). This data completion is important as, otherwise, it could happen that the DSS did not reach all the corresponding consequences (diagnoses). This part can be understood as a facts completion system and it is inspired by and loosely related to the process of adding hypotheses in geometrical theorems introduced in [31].

General Architecture
The subsystems are arranged in a cascade. The end user is informed of the data he/she should introduce to the previous definitions subsystem. From here onwards each subsystem could return no more information or more information could be extracted by the system. Anyway, all the available data are used by the next subsystem as input.
If the user introduced all the necessary information at every step and the DSS did not ask for more test to be carried out (situation (i)-(b), see Section 3.1), the flow between subsystems would be trivially straightforward (Figure 4, left).
However, as said in Section 3.1, in all subsystems the need to perform further tests (situation (i)-(b)) or a data completion (situation ii)) could be required by the DSS.
For instance, if the situation described in (i)-(b) took place, for example, in Subsystem IIIa, and the DSS asked for an "exercise electrocardiogram" to be carried out, when these new data were obtained, the knowledge extraction process would have to be restarted (Figure 4, right). Observe that this sort of loops could arise more than once.
Something similar would happen if the end user had not given the system all the required information. This is the case when one variable in the antecedent of a rule is neither stated as true nor as false, meanwhile another variable in the antecedent of the same rule is stated as true or deduced to be true by a previous subsystem (situation (ii)). The DSS would need to be rerun in such a case (after the data completion).

Variables Considered
The variables in the antecedents and consequents of the rules in the five subsystems are organized below in in Tables 1-6. Note that these tables just list these variables, there is no special relation between two variables in the same row.

New Variables in Antecedents
New Variables in Consequents riding_horse arrhythmia_during_exercise risk_ventricular_arrhythmia_during_exercise risk_supraventricular_arrhythmia_during_exercise HR_above_220 Knowledge extraction is performed in the following way: for each variable in the consequents of the rules of each subsystem it is checked if it follows from the conjunction of the variables in the antecedents that were stated as true or were obtained by forward firing. It is based on the use of Implies command from Maple's Logic package (see Section 4).
The process of determining through knowledge extraction that more data have to be introduced to the system (for instance that a certain test has to be carried out is identical to the process just described).
The different subsystems have, respectively, 11, 8, 7, 8/11, and 7 rules, so the whole DSS has 52 rules. Please note that the consequents of many rules are not simple (they are not Horns clauses, as required by other approaches). Simplifying the rules would result in a much bigger number of rules, but we have tried to stay as close as possible to the way the knowledge was expressed by the expert.

Data Completion Process
Some extra variables have to be considered for the data completion process, that are used by the data completion procedure in order to ask the end user which input data to complete.
For instance, those corresponding to the Previous Definitions Subsystem are: knowing_if_left_side_or_right_side_is_required knowing_if_PMI_aorta_or_mitral_is_required knowing_if_grade_1_to_3_or_4_to_6_is_required knowing_if_normal_or_very_low_or_high_HR_is_required knowing_if_very_low_or_high_HR_is_justified_or_not_is_required The process of data completion is treated separately from knowledge extraction, and it is performed by a long procedure denoted required_check(), written in imperative programming style (not based on knowledge extraction). It checks the rules looking for incomplete declaration of the truth of the variables in the antecedents. Then it asks the end user to assign truth values to those variables.
An example is the following: suppose that the end user had only introduced dias-tolic_murmur as input datum. According to rule R5 (already detailed above): R5: IF diastolic_murmur AND left_side AND PMI_aorta THEN AoI the user should have informed the system whether left_side holds or not as well as whether PMI_aorta holds or not. Then the system would ask the end user that: knowing_if_left_side_or_right_side_is_required knowing_if_PMI_aorta_or_mitral_is_required This is achieved by many lines of trivial imperative code based on checking set membership conditions in simple conditional statements and grouped in a single procedure. The programming is simple although laborious. See Section 4 for details.

Maple Implementation
The system is going to be tested firstly in Spain so the variables in this first version of the implementation are in Spanish. Nevertheless, the terms are close, except soplo (murmur). It will be translated to English once tested by a team of equine veterinarians and equine cardiologists.

Maple Implementation-Process (i)
The Maple implementation is straightforward. A global variable IFP is initialized as the empty set and their conjunction is stored in variable RP: RP:=RP1 &and RP2 &and RP3 &and RP4 &and RP5 &and RP6 &and RP7 &and RP8 &and RP9 &and RP10 &and RP11: Similarly, rules of subsystems I, II, IIIa, IIIb and IV are named RSIn, RSIIn, RSIIIan, RSIIIbn and RSIVn, where n is a positive integer. Their conjunctions are stored in variables RSx where x is I, II, IIIa, IIIb or IV.
Variable TR stores the conjunction of all RSj and Lconseq is the list of lists of variables in the consequents of the rules of the different subsystems. Finally, procedure exhaustive_check checks one by one which of the consequents of the different subsystems can be deduced from the known data of the horse: exhaustive_check:=proc(horse_data) local i,j,res; for i in Lconseq do for j in i do res := Implies( TR &and horse_data , j ); if res=true then print(j) end if; end do; end do; end proc: The approach is naive, but the number of rules is limited and at this first step we wanted to check the possibilities to develop a working prototype and to debug it. A

Maple Implementation-Process (ii)
It is performed by procedure required_check, a procedure written in imperative programming style, with several simple lines of code such as: Tuti is the union of the set of given data (variables sated as true by the user) and the set of variables obtained by forward firing of the rules, and • IFP is the set of given data and their negations.

Example I
Please note that input lines are preceded by > symbols and output lines are centred. The computation times are expressed in seconds (the examples have been run on a standard portable computer).
In this first example, the end user just introduces one datum: &not auscultacion_-ritmo_regular. The system gives a partial diagnosis: sospecha_arritmia and sospe-cha_relevancia_clínica and asks for more tests to be performed ("estudio cardiaco", "ecocardio", "tensiometría", "electro en reposo"). Meanwhile, exhaustive_check asks for many data to be introduced (propositional variables that have to be stated as true or false).
> required_check(FP); Nota i: si el sistema "requiere_saber_x" añadir como cierto "x" o "&not x" Nota ii: si el sistema "requiere_saber_x_o_y" añadir como cierta "x" o "y" - After the new data were introduced new conclusions could be reached but also more data could be required (remember that the subsystems are arranged in a cascade and loops can appear in this cascade).

Example II
In this second example, the user introduces some data about the horse. The system gives a partial diagnosis (IAO). Again, exhaustive_check is run and asks for more data. After the new data were introduced new conclusions could be reached but also more data could be required (remember that the subsystems are arranged in a cascade and loops can appear in this cascade).

Results
The authors designed, developed and implemented a prototype of DSS for equine cardiovascular diseases diagnosis and management. This was an unexplored field, as far as we know. Therefore, an innovation of this work is the field of application of DSS techniques and knowledge.
The organization of the equine cardiology knowledge in the form of mathematical rules was a long work that required close collaboration of the two authors and a careful debugging.
The knowledge extraction part of the DSS was straightforward to implement as it uses well known techniques. It is performed by the exhaustive_check() procedure that exhaustively checks which diagnoses can be obtained by forward firing the rules in the DSS given the horse's data introduced by the end user.
Nevertheless, the first tests of the DSS showed that, in most cases, an unaware vetrenarian (one that was not an equine cardiologist), would not introduce much auxiliary data, which would prevent the DSS from obtaining all the appropriate conclusions. This happens because the potential facts can be stated as true or false or perhaps nothing is said about them. A rule is fired if and only if its antecedent is true, which requires all the variables in it to be adequately stated as true or false. Therefore we developed a second part of the DSS (that consists of a long procedure, denoted required_check(), written in imperative programming style, i.e., not based on forward firing rules) that checks rules with undefined variables in their antecedents and asks the end user to assign to those variables either the "true" or the "false" value. This data completion part of the DSS is another novelty of the work (motivated by the possible lack of specialization of the user -a veterinarian).

Conclusions and Further Work
We believe this could be a very useful DSS, because cardiac diseases are not very common in horses, so a small proportion of veterinarians have a background in equine cardiology. Let us underline that it does not try to substitute the specialist, but to help a general veterinarian or a veterinarian that is not an equine cardiologist to help in deciding, for instance, whether to refer the horse to a cardiologist or not or whether to retire a horse or not. The initial target end user (a general veterinarian) has to reply the questions asked by the DSS and to perform the tests required by the DSS (for instance, an ecocardiography). The possibility to carry out the latter obviously depends on their qualification and the available equipment.
Nevertheless, it can also help an equine cardiologist in obtaining a second opinion from the set of data of a real case. This is a first design, development, and implementation of a prototype. It would have to be extensively tested and debugged, prior to real life use.
However, it also has strong educational potential. It can be used in its present state in the veterinarian cardiology classroom (in a "supervised work" approach), as well as for performing "autonomous homework". Moreover, the first approach could give the first feedback for the DSS debugging.
Although not very important as the implementation is fast, it would be more elegant if recomputing was avoided by storing the conclusions of the previous subsystems with completed data. That could be a future task.
From the computational point of view, other alternative approaches should be explored and tested. Maple was chosen because it is really friendly and development times are excellent, although it has the disadvantage that it is a commercial CAS, which can limit the use of the DSS.
Moreover, a comfortable GUI should be developed for its real use, as the target end user is not supposed to be a programmer. An advantage of using Maple is that its last versions have enhanced their possibilities to develop friendly windows-based applications.

Conflicts of Interest:
The authors declare no conflict of interest.

Abbreviations
The following abbreviations are used in this manuscript: