Informal, Formal and Operational Modelling of Medical Guidelines
Vojtěch Svátek1, Antonín Říha2, Tomáš Zíka2, Jana Zvárová2, 
Radim Jiroušek1, Zdeněk Zdráhal3
1 Laboratory for Intelligent Systems, Faculty of Informatics and Statistics, 
University of Economics, Prague, W.Churchill Sq.4, 13067 Praha 3, CR 
2 European Centre for Medical Informatics, Statistics and Epidemiology of Charles University and Academy of Sciences, Pod Vodárenskou věží 2, 182 07 Praha 8, CR
3 Knowledge Media Institute, The Open University 
Walton Hall, Milton Keynes MK7 6AA, UK
E-mail: {svatek,radim}@vse.cz, {riha,zika,zvarova}@euromise.cz, z.zdrahal@open.ac.uk
Abstract. Formal representation and automatic processing of medical guidelines is one of the foremost challenges in applied knowledge engineering. We describe a new, flexible model of medical guideline, which seems to be particularly suitable for analysis of guidelines with respect to patient records. To provide for clear transition between the analysis and design phases of development of guideline–processing software, we formulate the model at various levels: informal, formal and operational. For the first one, we use structured text plus diagrams, while for the latter two, the OCML (Operational Concept Modelling Language) seems to be suitable, since it enables both formal checking of concept definitions and execution of operational specifications. The model is currently being tested in the hypertension domain.
1	Introduction
Medical guidelines (MG) are a standard means for dissemination of medical knowledge and for putting through healthcare standards in various areas of medicine. In addition to the textual (be it paper or electronic) form of MGs, attention is currently paid to the possibility of their formalisation and computational processing. In the European project MGT (Medical Guidelines Technology) of the 4th framework programme, we attempt to convert medical knowledge hidden in the textual form of MGs into a simple yet rich and flexible representation, and to connect it with electronic patient records (EPR). The interaction between MGs and EPRs can then have different forms, such as:
•	support of a physician in the course of decision–making
•	posterior comparison of the actions undertaken by a physician with the MG
•	critique and suggestion of revision of the MG based on analysis of  multiple EPRs
•	comparison of several MGs from the same domain, with respect to their impact on a target population (and thus, indirectly on the EPRs).
	Each of these ”modes of work” requires a different computational model but all should rely upon the same representation of medical knowledge and format for data. In designing this representation, several characteristics of MGs should be taken into account. 
	MGs aim at supporting the diagnostic and therapeutic activities of a physician. This is done in both prescriptive (or, procedural, algorithmic…) and descriptive (or, declarative) manner. In ordinary cases, the interpretation of prescriptive knowledge, such as decision trees or tables, is relatively straightforward, but vague statements still have to be instantiated by concrete values. Descriptive knowledge (such as causal relationships) is, again, hard to interpret. Furthermore, the use of background knowledge not present in the text but common to physicians is implicitly assumed. Also, the guidelines are often inapplicable on rare, untypical cases. Finally, most guidelines describe sequences of events in the course of time; they can thus not be easily captured by means of shallow situation–action rules.
	The construction of guideline models, formalisation of concrete MGs, as well as the development of algorithms for processing such models, require a combination of skills pertaining both to knowledge engineering and to general software (and database) engineering. An important issue is that of reusing knowledge from previous projects from the same or similar domains. It is also clear that each step has to be carefully validated from the medical point of view. 
	In this paper, we describe the output of the first phase of this effort: a generic model for representation of the MG (domain ontology and representation ontology), as well as particular tools and formalisms used to express this model. In section 2 we describe the model at an informal level, using structured text and diagrams. In section 3 we proceed to the formal level of description, which is, thanks to the properties of the OCML language, closely related to operationality (executability) of parts of the model. Section 4 is devoted to examples taken from our pilot domain of hypertension treatment. Finally, section 5 points at related work, and section 6 summarises the results and outlines perspectives for the future.
2	Informal Modelling: Structured Text and Diagrams
The first phase of any knowledge modelling activity is focused on informal and semi–formal representation of knowledge. Such representation may be textual or graphical, but highest expressivity can be achieved through a combination of both. We will present our model both as structured text and as diagrams more–or–less compatible with the UML graphical language.
	Our informal model consists of two parts:
•	A guideline domain ontology, which describes the most important concepts dealt with in the guideline text, their attributes, and semantic relations among them
•	A guideline representation ontology, which defines how the concepts (not necessarily all of those listed in the ontology) can be embedded, aggregated and linked so as to make up the overall syntactic structure of the guideline. The informal representation ontology is a starting point for a prospective formal language in which guideline knowledge will be input into target applications.
2.1	

Figure 1: Diagram of the guideline domain ontology

Guideline domain ontology
	The diagram at Figure 1 depicts the most important classes from the guideline domain ontology, and the relations among them. As an example of textual description, for the “activity” class, see Table 1. Due to complexity constraints on diagrams, several classes are described in the textual form of the ontology only.
The prescriptive knowledge in an MG consists of elements determining „what“ should be done and „under what condition“ it should be done, which correspond to classes action and decision, respectively, in the domain ontology. Actions and decisions follow each other in time, either immediately or with a delay. Main subtypes of action are one–shot therapeutic (or diagnostic) procedure, as well as the start, end or change of a long–term process (therapy or monitoring); we call this process activity, consistently with the recent proposals within the commonly used EON Protocol Model [8]. The difference between an action and an activity is based on time: while an action (as well as decision) takes place within a single time point (such as patient’s visit), the activity has measurable duration and is delimited by actions of type “start” and “end”, respectively. A “snapshot” of activities in a given time point can e.g. give information on the drugs currently administered, without having to scan the database retrospectively and seek their prescription. An activity can be ended regularly, as its assigned time expires, or can be interrupted, if its exit condition is evaluated as satisfied. The exit condition can be related to the goal of the treatment (e.g. if there is surprisingly good response to the treatment and the blood pressure is sufficiently lowered, the drug treatment can be ended before than expected). It can also describe undesirable conditions (adverse effects of drugs, which force their administration to be terminated). In addition to prescriptive information (“how” to proceed), we also want to capture descriptive information – the goals to be reached by the treatment. This is done by means of the patient state class, which associates clinical parameters with time specifications, such as “patient has had normal blood pressure for at least three weeks”. 
activity
Process which has duration; its temporal aspect is described by means of a time specification. An ACTIVITY can be either TREATMENT or (passive) MONITORING.
Note: We do not consider an activity of type "waiting", as it is implicitely defined by a GUIDELINE ELEMENT with timing different from „now“.
Attributes:
•	description (long string)
•	generic time (time specification)
•	actual start (time point)
•	actual end (time point)
•	exit condition (relation to PATIENT STATE)

Table 1: Fragment from the semi-formal version of the guideline domain ontology
2.2	

Figure 2: Diagram of the guideline representation ontology

Guideline representation ontology
The guideline, as a complex object, is supposed to be represented as consisting of four types of descriptive elements: goals, scenarios, causal relationships and concept definitions.
•	goals express desirable states (of the whole treatment, or within a certain context)
•	scenarios express relations between conditions (as patient states and history) on the one side, and recommendations of steps to be taken (as simple action steps, as well as decision steps which again lead to action steps) on the other side
•	causal relationships express relations between actions/activities and clinical parameters on the one side and clinical parameters on the other side; they may include information on time delays
•	concept definitions define the criteria for being an instance of a certain concept, and prescribe how the values for variables (clinical parameters or the like) can be computed.
	In addition, two higher–level structures will be superposed on the descriptive elements: a network of scenarios, which reflects the order of steps (prescriptive aspect) recommended by the guideline, and a network (lattice) of patient states defined by the guideline, which reflects the similarity of states. Since the order of steps is defined only as a secondary structure upon scenarios, the model can be applied flexibly in the sense that a deviation from the recommendations does not entail its subsequent inapplicability on the patient. 
	Figure 2 depicts some aspects of the representation language graphically.
3	Formal and Operational Modelling: OCML
OCML (Operational Conceptual Modelling Language) has been developed at the Knowledge Media Institute of the Open University, UK. It is destinated for formalization and operationalization of knowledge models such as ontologies or problem–solving models. Its representation combines a relational approach with object–oriented approach and with basic procedural constructs such as loops and conditioning. The OCML inference engine, which serves for evaluation and „execution“ of models, combines three main strategies:
•	theorem–proving analogical to Prolog, including backtracking on failure
•	inheritance of attributes along class hierarchies
•	procedural calls to the functional language CommonLisp [7], on the top of which the OCML engine is running.
	Our way of using OCML is concentrated on building a library of data structures, procedures and functions that correspond to constructs (and ways of their evaluation) typically occuring in MGs. Elements of this library can later be used by MG–processing applications.
	As first, rather simplified, examples, we can introduce the classes „person“ and class „visit“. The latter corresponds to the event of the patient visiting the physician, and includes measurements of temperature and blood pressure as its attributes.

(def-class person ()
           ((ID :type string)
            (name :type string)
            (smoker :type string))).
(def-class visit ()
           ((date :type string)
            (ID :type string)
            (temperature :type real)
            (sbp :type integer)
            (dbp :type integer))).

	Individual persons then can be defined as instances of the class „person“:

(def-instance pat_1 person ((ID 123456)(name John)(smoker YES)))

(def-instance pat_2 person ((ID 234567)(name Joseph)(smoker NO)))

	Information on visits of a particular person can be obtained using the query

ask (visit ?a 
	ID (the ?q (person ?w ID ?q name John)) 
	date ?b temperature ?c sbp ?s dbp ?d ))

	The query combines instances of the two classes using the function „the“, which picks up the value of variable „?q“. The „ask“ query mechanism enables to make the inference engine backtrack; we can thus obtain multiple instances relevant to the query, in turn.
Surprisingly enough, an attribute can have multiple values at the same time – the reason is that classes are internally defined as unary relations and attributes as binary relations. As an example, let us define the class „variable“ with a single attribute „value“:

(def-class variable ()
           ((value :type real)  )).

	All values of this variable can be obtained via defining a function which has the predefined function setofall in its body:

(def-function GetAllValues (?p) 
:body (setofall ?x (variable ?p value ?x))).

	Finally, we will introduce an example of relation, which formally defines a difference between two dates (e.g. of encounters):

(def-relation  date-difference (?date-1 ?date-2 ?diff ?diff1))
(def-rule date-difference 
  ((date-difference ?date-1 ?date-2 ?diff ?diff1)
     if
   (and 
    (date ?date-1 day ?d1 month ?m1 year ?y1)
    (date ?date-2 day ?d2 month ?m2 year ?y2)
    (not (== ?date-1 ?date-2))
    (= ?diff1 (+ (* (- ?y2 ?y1) 365) (* 30 (- ?m2 ?m1)) (- ?d2 d1)))
    (> ?diff1 ?diff))))

	For more details on OCML, see [3].
4	Application in the Hypertension Domain
Hypertension treatment is an example of medical task in which patients are observed for a long period, measurements (in particular, of blood pressure – BP) are repeatedly taken, and activities (most often in the form of drug administration) are carried out.
	In our example, let us start with a text from a particular hypertension MG. According to the 1999 WHO/ISH Hypertension Guidelines for the Management of Hypertension [1], “the primary goal of treatment of patients with high blood pressure is… treatment of all reversible risk factors as well as restoration of blood pressure to normal or optimal levels.” The representation of the guideline should thus contain the above two goals (treatment of risk factors and lowering of BP), as well as the definitions of the concepts of high BP, reversible risk factors, and normal or optimal BP. In addition to textual and graphical representation, the guideline model can be expressed in OCML. 
	As an example, let us take the general definition of blood pressure level. We will express it as ternary relation among systolic BP, diastolic BP, and a term denoting the level (such as normal, optimal, hypertension, etc.):

(def-relation bp-level (?systolic-bp ?diastolic-bp ?level))

	If we want to use this relation for determining the level for a given pair of systolic/diastolic BP, we further need a rule (note that there could be several such rules for a given relation):

(def-rule bp-level-determ
    ((bp-level ?systolic-bp ?diastolic-bp ?level)
     if (and 
		   (bp-level-table ?bp  bp-level ?level defining-condition or
                       systolic-min ?syst-min systolic-max ?syst-max 
                       diastolic-min ?dias-min diastolic-max ?dias-max)
          (or (between ?syst-min ?systolic-bp  ?syst-max)
              (between ?dias-min ?diastolic-bp ?dias-max))))

	The rule states that BP level can be computed from systolic and diastolic BP, through comparison with values taken from the “bp–level–table”, which is another relation.
	The representation of the guideline further contains a large number of scenarios, which can be exemplified in a semi–formal way e.g. as:
•	CONDITION: patient is in state “eligible for hypertension treatment”; RECOMMENDATION: perform action: start–activity “Lifestyle measures”; perform decision: according to patient’s prognosis, decide if drug treatment is to be started.
•	CONDITION: patient is in state “medium risk prognosis”; patient’s history shows that “BP monitoring” activity is going on for less than 3 months; RECOMMENDATION: continue with “BP monitoring” activity.
	Causal relations among BP, various clinical parameters and associated conditions are also present in the guideline text and can be thus included into the representation.
5	Related work
Since medical guidelines are one of the hot topics in up–to–date (applied) knowledge engineering, several projects have emerged, which aim at their formalisation and exploitation. Beyond the MGT project, it is, in particular, the Asgaard project [6], conducted in co-operation between the Stanford University and the Austrian Research Institute for Artificial Intelligence. The main ideas of Asgaard are to discover implicit intentions of the guideline and of the healthcare provider, and to compare them at an abstract level. For this, powerful mechanisms for conceptual as well as temporal abstraction have been devised. Among the European projects of the 4th framework programme, we should mention HC-REMA, its follow–up PatMan, PRESTIGE, PROGUIDE and PROMPT. The main targets of the first two is to create a mapping between the rather vague directives of MGs and more concrete requirements imposed by day–to–day assignment of (both human, technical and financial) resources in a hospital environment; the representation of MGs is based on the formalism of Petri nets, in which patients correspond to tokens moving between the nodes. The aim of PRESTIGE is to develop infrastructure for dissemination and application of medical guidelines based on up–to–date medical knowledge and to contribute to the development of standards for clinical practice. The PROGUIDE project aims to improve the availability of medical guidelines by means of a WWW server that provides information on existing guidelines, as well as persons and institutions involved in their implementation and quality assurance. The PROMPT project aims to create a clinical workstation, combining components like EPR, decision support and protocol development software, multimedia knowledge reference system and telematic technology. From the above mentioned projects, the MGT is close to Asgaard in its aiming, since it attempts to surpass the ”procedural” view of an MG toward a ”goal–oriented” view. The guideline model contains fewer primitives than that of Asgaard, which is motivated by the need of comparison with large volumes of data. The use of OCML also provides a smoother transition from abstract models to executable code.
6	Conclusions and Future Work
We have presented a generic model of medical guideline, and its application in a specific domain (hypertension treatment). Construction of the model was the first step in designing a complex of software tools for guideline–based support of treatment, healthcare evaluation, and guideline analysis and critiquing. The elaboration of algorithms for the above tools is the next task to be solved within our project. In the model itself, certain parts need to be deepened, so that it covers all important concepts and relations. In particular, the area of drug treatment (drug groups, indications, interactions, costs) requires further elaboration.
	More attention should be also paid to the connection with electronic patient records. Multimedia patient record ORCA (Open Record for CAre) is a system that integrates the possibility of structured patient data entry including history, medication, symptoms etc. with multimedia objects as ECG, angiography or laboratory data [3]. Structured data can be entered either using custom–prepared forms or directly using a “knowledge tree”. The structure on data makes subsequent statistical processing and translation of entered data into other languages easier. The ORCA system has been validated in two Czech hospitals and in one Slovak hospital [8]; we are currently investigating how structured data extracted from the database can be processed with the operational code in OCML. When this problem is solved, we can proceed to more extensive tests on real medical data.
	In a longer term, our project should involve processing of uncertain information (by means of probabilistic models) and induction of hypotheses from large patient databases.

The work on this paper has been supported by the Copernicus PL973121 (MGT – Medical Guidelines Technology) Project within the 4th Framework Program of the European Union, by the grant no.VS96008 (Laboratory of  Intelligent Systems) of the Czech Ministry of Education, and by the grant no.201/00/D045 (Knowledge model Construction in Connection with Text Documents) of the Grant Agency of the Czech Republic.
References
[1]	WHO/ISH Hypertension Guidelines for the Management of Hypertension. Journal of Hypertension 17, 1999, 151-183
[2]	Dazzi L., Fassino C., Saracco R., Quaglini S., Stefanelli M.: A Patient Workflow Management System Built on Guidelines. Proceedings of AMIA’97, Nashville 1997, p.146-150.
[3]	Motta E.: Reusable Components for Knowledge Modelling. IOS Press, 1999.
[4]	Pierik F.H., van Ginneken A.M., Timmers T., Stam H., Weber R.F., Restructuring Routinely Collected Patient Data: ORCA Applied to Andrology. Methods Inf Med 36, 1997 184 - 190.
[5]	Schreiber, G. et al.: Knowledge Engineering and Management: The CommonKADS Methodology. MIT Press, 1999.
[6]	Shahar Y., Miksch S., Johnson P.: The Asgaard Project: A Task-Specific Framework for the Application and Critiquing of Time-Oriented Clinical Guidelines. Artificial Intelligence in Medicine 14:29-51, 1998.
[7]	Steele, G.: Common Lisp the Language, 2nd edition. Digital Press, 1990.
[8]	Tu S. W., Musen M. A.: A Flexible Approach to Guideline Modeling. 1999, Stanford Medical Informatics Technical Report SMI-1999-0789.
[9]	Zvárová J., Hanzlíček P., Přibík V.: Application of Orca Multimedia EPR in Czech Hospitals. In: Proceedings of the EuroRec '99 Conference,  Sevilla, 1999