Patient assessment and nding their critical issues is a crucial aspect of patient care, which is addressed by a medical work ow called the ABCDE approach. However, the ABCDE guidelines are only described in a textual way and hence are not automated. Human errors in practical use might occur, e.g. by persons new into the domain. In this paper, we propose a technical solution to support medical sta during the ABCDE assessment tasks by helping to decide if a patient is critically ill or injured and prioritize particular treatments for better and faster therapy. The solution is built upon a set of semantic rules and automated using the rule-engine \Prova".
Medical sta in emergency rooms and paramedics in emergency scenes are
usually confronted with patients they do not know. This means they are unaware of
their current medical status, what has happened to them, and where or whom to
ask about details. Emergency cases have a unique characteristic for the persons
who need to treat patients - the focus during processing is on high important
body functions while having in mind, some body functions are less important
for surviving the illness or accident [
The ABCDE approach is a basis in many training formats (e.g., ERC
(European Resuscitation Council), NAEMT (National Association of Emergency
Medical Technicians), AHA (American Heart Association)) [
The paper describes a technical approach to support the decision and actiontaking concerning the ABCDE approach for paramedics in training or emergency physicians. The goal is not only to provide support for the ve steps (as ABCDE suggests), but our solution also details every step and supports the decision whether a patient is critically ill and needs treatment within a hospital (e.g., a trauma-center or intensive care unit), or the patient is not critically ill and therefore care at a physician's o ce is su cient. This technical support also helps emergency doctors who do not complete the entire ABCDE approach and tend to forget essential points [11].
Personal health-tracking tools and more and more available personal medical data [15] might lead to the idea to take a decision about critical illness already during the emergency call, so that the emergency dispatcher can decide early to send specialists to the emergency scene and already book intensive-care-beds in advance. However, several papers that analyse the ABCDE approach advise paramedics and medical teams to do a best e ort in the initial patient assessment and it seems there is no technical approach yet to support this sort of work ow, even if there are still issues in performing the ve steps.
In the following section, we describe the ABCDE approach from a practitioner's viewpoint and which technical solutions might be possible to apply to it. In section 3 we describe our approach to deliver an at most exible solution without the need to change software deployments. In the results-section (4) we evaluate our solution with practical examples and then we discuss it in section 5. Finally, we conclude and mention future work in section 6.
This paper contributes by delivering a technical solution for the currently non-technical ABCDE approach in order to support medical sta in making faster decisions. 2 2.1
The ABCDE approach is used in patient assessment for nding critical illnesses or injuries and in treatment [20]. This approach was developed by experts in the emergency eld and is applicable in any emergency case to any patient group. ABCDE is an abbreviation for Airway, Breathing, Circulation, Disability, and Exposure.
This acronym is used to remind medical sta or paramedics about the order of the checks. They are ordered by importance, and the purpose is to treat rst what kills rst [23]. Every step has an outcome - either a \everything ne, proceed"-result or a \stop here - apply treatment, take a decision for immediate transport or call for specialist". All these tasks contain more factual information: the particular checks to be done, which treatment to apply, upper and lower limits for vital signs. The approach allows starting from the very beginning, once an issue is xed. For example, if the airway is blocked, a \stop and treat"result will occur. Once the paramedic is able to resolve the issue, the paramedic is forced to restart the entire ABCDE approach and nd subsequent issues.
The overall result of the entire ABCDE approach is either critical or not critical. These two impact patient treatment, priority within a treating facility (e.g., hospital, the ambulance car), and the following urgent procedures for medical sta .
From a more generic viewpoint, the ABCDE approach can be considered as a medical work ow. The ABCDE approach displayed in gure 1 (without exceptions) maps to a sequence-work ow-pattern [21]. This is because every check Airway check Breathing check Circulation check Disability
check Exposure step in the ABCDE approach is a single task, but the next one can only proceed if the previous is successfully completed. The start event involves a medical person's involvement, and the end of the task sequence is the nal result. This sequence (work ow) pattern, when taking into account the subsequent tasks, of the entire ABCDE approach maps technically to an 'exclusive-choice-work owpattern' [21]. The expansion is needed because if a medical check (e.g., on the Airway) is not successful, another work ow branch proceeds. Each sub-branch includes manual interventions, instructions, and decisions that need to be taken.
BPMN (Business Process Model and Notation) [
From a technical perspective, the decisions taken within the medical work ow are rules [10]. The "check-result" of any decision-point is depending on multiple parameters. So the rules decide on the path to be followed in the sequence. For example, the "check Breathing"-decision-point depends on whether the patient breathes normally and on oxygen saturation greater than 95%. Therefore the rule decides for true (=yes) only if the two mentioned functions evaluate to true; otherwise, the rule concludes false (=no).
The entire ABCDE approach is shown in gure 2. Since many publications provide a textual description of the ABCDE approach, these descriptions are still unclear, and they di er in detail, depending on the expert (-group) being involved. However, for our solution, the detail itself is not of importance, since it is just another parameter. 2.2
Research in clinical/medical decision support systems and the related work ows has a long history. One of the main contributors in the eld of clinical decision support is the Arden Syntax [17]. Another standard is the \Guideline Interchange Format" (GLIF3), which intention is about guideline-sharing. However, there are many more Clinical Decision Support Systems, but these two are essential because Arden Syntax is productively used, and GLIF3 takes care about sharing guidelines.
The structure of Arden Syntax follows so-called Medical Logic Modules (MLMs), which are collected out of di erent components. Namely they are \Maintainance", \Library", \Knowledge" and \Resources". All these components together are needed to build an appropriate knowledge base, to provide enough logic for taking clinical decisions [9]. From a technical perspective, a technician always needs to implement the MLMs, since the encoding of these modules is done for programmers and is not fully intuitive for an end-user. Furthermore, the provided examples [19] in the literature show that huge work ows contain a lot of if- else- clauses, in order to capture the entire work ow. This is because there is a need to take care about any detail in the conceptualization of the entire decision-path. However, the Arden syntax with the MLM structure is an established tool that is powerful in clinical decision support but seems too complicated for simple work ows like the ABCDE approach and needs an exact de nition of the particular work ow and possible outcomes (e.g., there is no mechanism for \negation as a failure" as in logic programming rules).
The approach using medical guidelines, with a focus on sharing, is the
Guideline Interchange Format (GLIF3) [22]. It was based on Arden Syntax and is
meant to be used for exchanging guidelines among di erent systems. GLIF3
creates owcharts of medical work ows containing an object-oriented
representation for decision tasks of the guideline [
perform ABCDE approach yes obviousCriticalBleeding
no proceedToCirculationCheck yes check Circulation
no GlucoseLevel < 50
yes apply Glucose
no alert "too low GlucoseLevel"
GlucoseLevel > 500
yes alert "too high GlucoseLevel"
no GCS < 12 no
yes alert "to low GCS - neurological deficites" pupilsisocore
no alert "Pupils not isocore"
yes strokeSigns
yes alert "StrokeSigns"
no disability not ok set clinical tasks alert Critical cinical task stop bleeding alert Critical proceedToDisabilityCheck yes check Disability proceedToExposureCheck
no yes checkExposure proceedToSecondarySurvey
no prepare for Transport to clinics submit evaluated information about Patient to clinics exposure not ok set tasks on exposure alert Critical
In this section, we represent the ABCDE work ow as logical rules, de ning the overall sequence and the expected outcomes of each rule. Secondly, we describe proceedToBreathingCheck yes check Breathing
no hasPulse yes
no start CPR alert Critical pulseRate between 50 and 100
no alert "Heart Rate too high/low"
yes systolicBloodPressure between >160 or <80
no alert "Systolic Blood Pressure too high/low"
yes circulation not ok set tasks on circulation alert Critical breathes yes
no start CPR alert Critical proceedToAirwayCheck yes check Airway no hasCyanosis
yes apply Oxygen
no alert "has cyanosis"
free airway alert airway not free
alert Critical chestExpansionSymmetric
no alert "has no symmetric chest expansion" respiratoryRhythmNormal
no alert "Respiratory Rhythm not normal" respiratoryRate between 8 & 20 per Minute
no alert "Respiratory Rate too low/high"
yes yes yes yes oxygenSaturation > 95%
no apply Oxygen alert "OxygenSaturation too low" set clinical tasks to al ow breathing breathing not ok alert Critical a proof of concept implementation using Prova-rule-engine. Thirdly, we outline a "hard-coded"-version of the work ow.
The ABCDE work ow is rigorous in the procedure. Therefore, the work ow does not allow any change in the order since the tasks are depending on each other. Furthermore, is it a must for the sequence to stop if any task is evaluated as \not normal". From a practitioner's perspective, these stops are crucial to deliver treatment to the patient at the right point of time, call for additional help, or prepare rapid transportation. 3.1
Representing the ABCDE approach in formal rules
As a rst step in transforming the medical work ow from a textual representation
to a technical support solution, there is the need for a formal de nition of the
applied rules. These rules can be represented as a set of horn-clauses [
Before de ning the rules in more detail, it is necessary to mention the following: the over-all-work ow sequence de nes the ABCDE work ow by itself. Secondly, each task of the sequence is also a rule that needs evaluation.
We de ne the check-results as follows (table 1): Using this information, we conclude every check results to be true if there is no critical issue in any of the single tasks. Therefore the entire result is not critical. If any of the checks resolves to false, the entire formula results in false therefore :notCritical, which means a critical outcome.
For the more detailed checks, some facts, which are essential for analysis, need to be de ned. This de nition is done on the patient's "should-be" status; healthy and everything as expected. The patient's vital signs, which are checked during the entire process and that need to be resolved as true are represented in table 2.
With this information available, the next step is in resolving the truth-values for A, B, C, D, E. These more detailed probes are the trigger for nding the critical values during the entire process.
For the checkAirway ( following rule.
A), the validation to airwayIsFree is done by using the A checkAirwayF ree(x) This means if the airwayIsFree resolves to true, A resolves to true, otherwise, A returns false, and subsequently returns a false for the notCritical.
Similar for the checkBreathing ( B) which concludes to true if, and only if the patient breathes, has no cyanosis, the chest expands symmetric, a normal respiratory rhythm, a respiratory rate is between 8 and 15 per minute, and oxygen saturation of the blood higher than 95%. Formulating this as a rule, give the following representation:
B breathes(x) ^ :cyanosis(x) ^ symmetricChestExpansion(x) ^respiratoryRhythm(x) ^ respiratoryRate(x; y; z) (3) ^oxygenSaturation(x; y) If the check Breathing results to true the circulationCheck ( C) is performed. It consists of checking if the patient has a pulse and if yes, the pulse rate and the systolic blood pressure are interesting. When formulating this as a rule representation, we get the following: C D
pulseCentral(x) ^ pulseRate(x; y; z) ^ systolicBloodP ressure(x; y; z) (4) The next in the sequence is the checkDisability ( D). It takes care of the blood glucose level, next to the GCS (Glasgow coma scale), if there is a symmetric reaction of the eyes and any stroke signs that are of high importance to take care of. Formulating this needs resolves to:
glucoseLevel(x; y; z) ^ GCS(x) ^ pupilsisocore(x) ^ strokeSigns(x) (5) The last step in the ABCDE approach is the checkExposure ( E). This check results in yes/no-answers, where the "no" is the needed one, and therefore the true/false mechanism is ipped. For example, the hasBleeding resolves to true if there is no bleeding, but it is false if there is bleeding. The same applies to the other functions.
E
hasBleeding(x)^hasBrokenBone(x)^hasAllergies(x)^hasP ain(x) (6) During the entire process, the solution needs to take care of outcomes. This means, no matter if a result is positive (notCritical, or an \Exception" is happening during the ABCDE sequence, this result needs to be communicated to the consumer of the work ow. Thus, we included an additional predicate to send messages by using Prova as a rule engine. These messages contain information about the outcome(s), which is dispatched to the initial caller of the Prova service. 3.2
Proof of concept implementation using Prova Having a formal representation of the rules is an advantage for a proof of concept implementation. For our implementation we are using a rule engine. A ruleengine separates the business logic from program logic [12] in a declarative rule representation. Considering the ABCDE approach as \business logic", we can easily change or extend the approach and the di erent checks without the need of changing program code, which takes care of the alerting mechanism itself. Even if di erent healthcare organizations need to have their individual procedures because of di erent levels of expertise, the same software stack can be applied by only changing the rule logic. Also, suppose there are new ndings in medical research targeting changes in the logic. In that case, an alignment can quickly be done without the need to deliver new software to an organization or an individual.
The procedure in our solution: The rule-engine (in our particular case) Prova5 [16], receives the message values, processes them and returns the outcome of the rule evaluation.
The Prova-syntax is prolog-style, and allows, on the one hand, to de ne facts, and on the other hand, the rules and goals. For our use case, we need to take care of all of the three elements. In more detail: From a user perspective, there is a user interface where the user can put all the information about a patient. If the user then hits the "submit"-button, the entered values are sent (in the form of JSON-RESTful-queries) to a Java servlet. The Java servlet receives the submission and then calls the rule-engine, with the con gured logic, and the "to be evaluated goal" (in here the notCritical ).
Prova evaluates all the con gured rules from section 3.1 and delivers the result back to the servlet. The resulting message from Prova back to the servlet is send using the sendMsg-function of Prova.
The sendMsg-function is a build-in-function of Prova that stops the work ow at the right point of procedure, with a correct error message. For example: if the airway is evaluated as \not free", the work ow stops and returns that an error in the procedure occurred and needs re-evaluation or treatment of this particular issue.
We de ne the following sendMsg -functions within the rules. In general, in order to get a result returned, if no error occurred during processing, we send a completed message so that the user knows that the check is completed. sendM sg(XID; osgi; "F HIR"; inf orm; "ABCDECheck" > completed): (7) 5 https://github.com/prova/prova
For any errors there are also messages to be sent back, to provide the user with information about the issue, and what to treat. For example: sendM sg(XID; osgi; "F HIR"; inf orm; "AirwayN otF ree" > AW ): (8)
The Prova rulebase is con gured to take care of the correct sequence of the ABCDE approach and stops if one is not successful. It also takes care of subsequent tasks for alerting. If everything is completed without any occurrences, the result is "completed" - no alerting, and a success message is send.
By implementing the work ow with Prova, i.e. a declarative rule representation, an advantage of our approach is the ease of extension. Any other work ow can be used by simply adding a new Prova- le containing the needed decisions. The generation of Prova les can be done by translating from the RuleML syntax. Due to the RuleML standard, this work ow is applicable to any other rule engine that supports RuleML or can convert from it, as well6 [13]. 3.3
Proof of concept implementation using Java As an alternative to using a rule engine, the entire work ow can be coded in a Java program with imperative if-then rules following a prede ned control ow. This is an approach that seems very obvious and has its legitimacy since, for a developer, it is an easy task to implement a method that covers the rules. However, this approach gets quickly confusing because of many decision points within the code.
In our proof of concept implementation for the hard-coded task, we used a small Java program containing a method, which receives the values from a JSON object and then runs the sequence. We had to take care of the di erent types that might be included in a JSON request and had to transform them to compare them. Concerning the Prova implementation, we did not face this problem, since Prova already handles types and comparison mechanisms. Furthermore, this approach is not exible for an organization to operate and maintain, and it is pretty expensive since every change needs to be re-implemented. If deploying the software in di erent organizations, every customer is forced to use another version. This hard-coded solution becomes cumbersome even if a limit change or an additional parameter needs to be checked.
The code about the implementation can be found on Github7. There is the Java implementation as well as the Prova implementation and the rules. 4
For the evaluation, we checked for the correct behavior of both implementation solutions. Since the evaluation focused on the correctness of the rule's results, we required the values submitted to be of the correct type or contained allowed 6 https://github.com/RuleML/rule-translation-service 7 https://github.com/gkober/MedicalRule values. For example, a number- eld contained a number, but not a text, and also the "yes/no"-questions had to contain yes or no. We sent 50 JSON queries containing di erent allowed values to both solutions and received the same results. A manual check of the target result was done, and the results from the manual checks matched the results from the implementation.
During implementation, we found a signi cant advantage of the Prova-rulebased version was the ease of extension of the ruleset. Adding the appropriate rules, saving the le, and re-running the development tests was comfortable in relation to implementing the comparison mechanisms in the Java-code-base.
The pure Java implementation hits some limits: so we need to use the correct values for the speci c types. For instance, "airwayFree" can not be yes or no - since Java can not handle it out of the box as boolean values. So we needed to convert to make sure the values are true or false. For a potential customer, who does not have a technical background, and only wants to implement the support tool for his organization, this hard to understand and eventually too technical. Furthermore, if the implementation takes care of this, we need to cover all possible "positive" results and convert them.
Additionally, failure processing gets quite complex, due to the many combinations, if there are multiple "wrong" results for the alerting mechanism.
Another problematic limit is the exchange of the rules. Suppose several locations (organizations) run the processing engine, and all need to ensure the same behavior as the local medical experts need it. In that case, it might get problematic to exchange the rules to all participants simultaneously. Having a standard like RuleML, which allows the interoperability of rules, helps to have a stable code base from a deployment perspective and an easy exchangeable part in the rules. 5
The objective of this paper was to nd a technical solution to support medical
sta during patient evaluation and nding the critically ill/injured people using
the ABCDE approach, and deliver the appropriate therapy. This is highly
relevant since physicians and paramedics in the eld tend to forget essential checks,
and patients are missing proper treatment [14][
We created a formal description of the rules applied during the ACBDE approach, also taking into account, there are exit rules that ensure stopping the algorithm at the correct point. A proof of concept implementation supports the general rule approach and compares di erent attempts of implementation. One implementation was done using the Prova-rule engine, while another implementation was done using only Java. Both methods were evaluated in terms of correctness. From our perspective, the more exible solution is the declarative rule-based version since the exchange or extension of rules is more manageable and not depending on a developer changing the behavior. The idea of using such a tool in the daily routine of paramedics or physicians needs to be evaluated, and a study of acceptance and results needs to be done.
This unique work ow is minimal and very strict in yes/no, and has very well described criteria when a patient is assessed as critical or not-critical. It is possible to apply the idea of representing and executing medical work ows in a rule engine for decision support. Using RuleML as rule interchange standard supports a broad eld of use, and is not focused too strict on the medical domain such as Arden syntax, or GLIF3, which e.g. might help in nding external reasons for illnesses. 6
In this work, we used a simple medical work ow called the ABCDE approach, which is well known amongst paramedics and medical sta , to represent it technically for supporting the medical personal during patient evaluation. Therefore, a formal representation of the work ow was done, including "second-level"-checks, to evaluate a work ow to critical or not-critical. This formal representation was then transformed into a proof of concept implementation to check for correctness. By now, the rule engine is relying on parameters that are provided. In the future, it is foreseen to include data queries (e.g., SPARQL-queries) to the rules and not to have the data in the incoming stream. This helps reduce the amount of transferred data if data is not necessary for evaluation.