I present a conceptual model of an evolving CIG in a formal (logic-based) specification. The evolving CIG conceptual model is mapped into an evolving CIG metamodel at layer M2 of the CIG modelling architecture of Fig. 5.2. The resultant UML Class Diagram of the evolving CIG conceptual model showing an informal overview is presented in Fig.5.3.
5.5.1 Conceptual model development: the process
The development of the metamodel was informed by both existing CIG modelling pro- posals and by obtaining modelling guidelines from foundational ontologies.
First, the metamodel builds on existing CIG modelling formalisms and refines it through explicitly specifying the fine-grained CPG components affected by CPG changes. GEM, GLIF, Asbru, PROforma, SAGE and Arden syntax were evaluated to identify guideline modelling primitives. The CIG metamodel was iteratively constructed by analysing the characteristics of each type of CPG change and subsequently including all elements that are affected by that particular change to the CIG metamodel. Decisions and actions were found to be the guideline representation primitives in existing guideline modelling languages, concurring with [2], and lacking vocabulary for elements such as decision variable values that can change (recall Fig.5.1: a value changing from ≤ 350 to ≤ 500). Thus, such entities were incorporated into the CIG metamodel.
Figure 5.3: UML class diagram of an evolving CIG
Second, with as aim to foster wide interoperability between CIG formalization systems, the CIG metamodel was extended by availing the knowledge from the Systematized Nomenclature of Medicine – Clinical Terms (SNOMED CT), which is an ontology that is one of the most comprehensive clinical terminology systems [279] and relatively widely used for electronic health records. In particular, the concept Decision Variable now refers to the same concept as Clinical Finding in SNOMED CT and the CIG metamodel was further extended by the concept Unit in SNOMED CT.
Third, noting that also SNOMED CT has been analysed with respect to the DOLCE foundational ontology [280], I considered foundational ontologies for further quality im- provements regarding the guideline modelling primitives. As a full linking to any of the foundational ontologies would introduce many new terms that are irrelevant for a prac- tical domain-specific modelling language, I decided to only borrow ideas from it. This resulted in an extension of the metamodel with the concept Relator from the General Formal Ontology (GFO), which is a foundational ontology for integrating objects and processes [281].
5.5.2 Precise specification of the evolving CIG conceptual model
This section specifies a precise semantics for the fine-grained CIG conceptual model pre- sented in Section5.5.1. The semantics presented in this section were expressed in OWL using the Prot´eg´e [282] ontology development environment. I use Berardi et al’s [283] encoding principles to map the informal CIG metamodel to a precise specification. Due to OWL’s rather verbose syntax, and OWL 2 Description Logics (DL) being essentially a serialisation of the ALCQ DL language, I present the CIG metamodel’s main axioms in DL notation to demonstrate its feasibility, with the usual semantics as defined in [284]. In the DL notation, ≡ means ‘equivalent’, u ‘and’, ∃ ‘at least one’, = n ‘only n, where n is an integer’, and ∀ ‘for all’. All classes are disjoint (axioms not included). The full specification in OWL is presented in AppendixC. The DL statements use the class and association names specified in Fig. 5.3. Each axiom in the formalisation listed below is illustrated with examples from the Malawi HIV guidelines.
Guideline ≡(∃hasRecommendation.Recommendationu ∀hasRecommendation.Recommendation)u (∃hasCondition.Condition u ∀hasCondition.Condition)u (∃hasAction.Action u ∀hasAction.Action) (5.1) Recommendation ≡(∃referencesCondition.Conditionu ∀referencesCondition.Condition)u (∃referencesAction.Action u ∀referencesAction.Action) (5.2) Condition ≡(= 1 hasDecisionVariable.DecisionVariableu ∀hasDecisionVariable.DecisionVariable)u (= 1 hasRelator.Relator u ∀hasRelator.Relator)u (= 1 hasVariableValue.VariableValueu ∀hasVariableValue.VariableValue) (5.3)
ConditionWithUnit ≡Condition u (= 1 hasUnit.Unit) (5.4)
Action ≡(= 1 hasActionVerb.ActionVerb u ∀hasActionVerb.ActionVerb)u (= 1 hasActionVerbComplement.ActionVerbComplementu
∀hasActionVerbComplement.ActionVerbComplement) (5.5)
First, a clinical practice guideline denoted by Guideline is defined in Eq.5.1, i.e., a Guide- line has at least one guideline recommendation denoted by Recommendation, and only
guideline recommendations. Guideline has as instance, e.g., “Definition of ART eligibil- ity” in the “2014 Malawi Integrated Guidelines for Providing HIV Services”. An example of a Recommendation is one for managing an “Infant under 12 months: Confirmed HIV infection (DNA–PCR needed)”. A Recommendation consist of at least one condition, denoted by Condition and at least one recommended action, denoted by Action to be executed on a patient when the all the conditions in the Guideline are satisfied (Eq.5.2). For instance, “HIV test result is positive” is a Condition and “Prescribe regimen 4” is an example of an Action. Delving into conditions, there are: decision variables, denoted by DecisionVariable; relators, denoted by Relator; and decision variable values, denoted by VariableValue, satisfying the constraints as in Eq. 5.3. For instance, take the Condition “HIV test result is positive”, which has as DecisionVariable “HIV test result”, Relator “is”, and a VariableValue “positive”. One can also have a unit, denoted by Unit, associ- ated with conditions that have units denoted by ConditionWithUnit, as in Eq.5.4; e.g., in the Condition “Age more than five months”, “months” is a Unit. Finally, a recommended action, denoted by Action, can be defined as in Eq.5.5, availing of an action verb denoted by ActionVerb and an action verb complement, denoted by ActionVerbComplement. For instance, “Prescribe regimen 4” is an Action, in which the ActionVerb is “Prescribe” and the ActionVerbComplement is then “regimen 4”.