Top Banner
International Journal of Medical Informatics 53 (1999) 61 – 77 Protocol-based reasoning in diabetic patient management Stefania Montani a, *, Riccardo Bellazzi b , Cristiana Larizza b , Alberto Riva c , Giuseppe d’Annunzio c , Stefano Fiocchi c , Renata Lorini d , Mario Stefanelli b a U.P.I.T. Consorzio di Bioingegneria ed Informatica Medica, 6ia Ferrata 1, 27100 Pa6ia, Italy b Dipartimento di Informatica e Sistemistica, Uni6ersita di Pa6ia, Pa6ia, Italy c IRCCS Policlinico S. Matteo, Pa6ia, Italy d Dipartimento di Pediatria, Uni6ersita di Geno6a, Instituto G. Gaslimi, Geno6a, Italy Received 5 January 1998; accepted 4 June 1998 Abstract We propose a system for teleconsultation in Insulin Dependent Diabetes Mellitus (IDDM) management, accessible through the use of the net. The system is able to collect monitoring data, to analyze them through a set of tools, and to suggest a therapy adjustment in order to tackle the identified metabolic problems and to fit the patient’s needs. The therapy revision has been implemented through the Episodic Skeletal Planning Methodi, it generates an advice and employs it to modify the current therapeutic protocol, presenting to the physician a set of feasible solutions, among which she can choose the new one. © 1999 Elsevier Science Ireland Ltd. All rights reserved. Keywords: Knowledge-based systems; Therapy planning; Diabetes mellitus; Telemedicine 1. Introduction It is nowadays well-known that the inci- dence and severity of later-life complications resulting from Insulin Dependent Diabetes Mellitus (IDDM) can be reduced if patients receive a treatment leading to good glycemic control, by maintaining a careful balance be- tween diet, insulin therapy and physical exer- cise [1]. These goals may be achieved if patients undergo Intensive Insulin Therapy (IIT), which involves three to four Blood Glucose Level (BGL) measurements a day or continuous sub-cutaneous injections. IIT has serious drawbacks, like the increase in risk of severe hypoglycemic events and the increase in treatment costs, due to the need for more frequent home assistance and continuous ed- ucation of patients. The benefits and prob- * Corresponding author. Tel.: +39 382 505511; fax: +39 382 505373; e-mail: [email protected] 1386-5056/99/$ - see front matter © 1999 Elsevier Science Ireland Ltd. All rights reserved. PII S1386-5056(98)00103-8
17

Protocol-based reasoning in diabetic patient management

Apr 27, 2023

Download

Documents

Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: Protocol-based reasoning in diabetic patient management

International Journal of Medical Informatics 53 (1999) 61–77

Protocol-based reasoning in diabetic patient management

Stefania Montani a,*, Riccardo Bellazzi b, Cristiana Larizza b, Alberto Riva c,Giuseppe d’Annunzio c, Stefano Fiocchi c, Renata Lorini d, Mario Stefanelli b

a U.P.I.T. Consorzio di Bioingegneria ed Informatica Medica, 6ia Ferrata 1, 27100 Pa6ia, Italyb Dipartimento di Informatica e Sistemistica, Uni6ersita di Pa6ia, Pa6ia, Italy

c IRCCS Policlinico S. Matteo, Pa6ia, Italyd Dipartimento di Pediatria, Uni6ersita di Geno6a, Instituto G. Gaslimi, Geno6a, Italy

Received 5 January 1998; accepted 4 June 1998

Abstract

We propose a system for teleconsultation in Insulin Dependent Diabetes Mellitus (IDDM) management, accessiblethrough the use of the net. The system is able to collect monitoring data, to analyze them through a set of tools, andto suggest a therapy adjustment in order to tackle the identified metabolic problems and to fit the patient’s needs. Thetherapy revision has been implemented through the Episodic Skeletal Planning Methodi, it generates an advice andemploys it to modify the current therapeutic protocol, presenting to the physician a set of feasible solutions, amongwhich she can choose the new one. © 1999 Elsevier Science Ireland Ltd. All rights reserved.

Keywords: Knowledge-based systems; Therapy planning; Diabetes mellitus; Telemedicine

1. Introduction

It is nowadays well-known that the inci-dence and severity of later-life complicationsresulting from Insulin Dependent DiabetesMellitus (IDDM) can be reduced if patientsreceive a treatment leading to good glycemiccontrol, by maintaining a careful balance be-

tween diet, insulin therapy and physical exer-cise [1]. These goals may be achieved ifpatients undergo Intensive Insulin Therapy(IIT), which involves three to four BloodGlucose Level (BGL) measurements a day orcontinuous sub-cutaneous injections. IIT hasserious drawbacks, like the increase in risk ofsevere hypoglycemic events and the increasein treatment costs, due to the need for morefrequent home assistance and continuous ed-ucation of patients. The benefits and prob-

* Corresponding author. Tel.: +39 382 505511; fax: +39382 505373; e-mail: [email protected]

1386-5056/99/$ - see front matter © 1999 Elsevier Science Ireland Ltd. All rights reserved.

PII S1386-5056(98)00103-8

Page 2: Protocol-based reasoning in diabetic patient management

S. Montani et al. / International Journal of Medical Informatics 53 (1999) 61–7762

lems of IIT motivate a growing attentiontowards information technologies for improv-ing diabetic patients’ care. Since the early ‘80s,many decision support systems for IDDMpatient management have been proposed. Anextensive review of the application of com-puter systems in diabetes care can be found inLehmann and Deutsch [2]. For the purposes ofthis paper, following Deutsch at al. [3], we willclassify these systems into two categories: dayby day advisory systems and visit by visitsystems.

Day by day advisory systems are mainlydevoted to supply therapeutic advice to pa-tients and physicians during the every dayself-management of the disease. Algorithmsfor insulin dose adjustments implemented intohand-held devices [4–7] can be found in thiscategory, together with more complex systemswhich provide optimal or suboptimal insulindose modifications on the basis of a model ofthe diabetic patients’ behavior [8,9].

Visit by visit systems are devoted to assistphysicians in interpreting the time series com-ing from home monitoring data and hence inrevising the therapeutic protocol that the pa-tient is following. Several examples have beenproposed to this end [10–12].

The most recent implementations try toovercome the weakness of traditional expertsystems [13] that used medical knowledge outof its natural context, without taking intoaccount the real features and needs of thehealth-care environment. Visit by visit systemsare aimed at improving the overall treatmentquality, and integrate the data management,the data interpretation and the decision sup-port task in a uniform way. An example ofthese integrated systems is UTOPIA/DIA-MOND [12], that couples data-base and deci-sion support in the same tool.

The information age has now enabled athird class of decision support systems, thatare aimed at combining the advantages of both

day-by-day and visit-by-visit systems: they aredistributed information systems (DIS), that,thanks to their distributed nature, provideadvice to both patients and physicians througha network connecting the patients’ house andthe clinic. Examples of these integrated frame-works are the DIABTEL system [14] and theHUMALINK system [15].

Although the use of DIS in Diabetes careneeds to be tested in prospective studies, thepreliminary results obtained, together with thecontinuous improvement of the availabletelecommunication infrastructure, pushes to-wards the definition of DIS that are morecapable of capturing the complexity of IDDMpatients management. To this purpose, theEU-funded TIDDM project [16] proposes aDIS based on a two-level hierarchical controlarchitecture based on two distinct and cooper-ating modules: a patient unit (PU) and amedical unit (MU). While the MU assists thephysician in the definition of the basal insulinregimen and diet through a periodic evalua-tion of the patient’s data, the PU helps thepatient collecting data, both manually andautomatically from a reflectometer, and trans-ferring them from her home to the clinic,moreover it supports the patients in theirself-monitoring activity, by suggesting the in-sulin dosage adjustments, if needed. From adecision-support perspective, the MU inte-grates a visit-by-visit assistance for the physi-cian with the possibility of providing telecareto patients, via the telecommunication linkbetween hospital and patients’ house. On theother hand, the PU gives day-by-day supportto the patients, allowing for intelligent alarm-ing and teleconsultation. The details of thearchitecture are described elsewhere [17,18].

In this paper we will concentrate on thedecision support functionalities implementedin the MU, whose goals are basically toprovide physicians with a flexible instrument

Page 3: Protocol-based reasoning in diabetic patient management

S. Montani et al. / International Journal of Medical Informatics 53 (1999) 61–77 63

for managing a large number of patients in asemi-automatic fashion, through an intelli-gent handling and customization of the dif-ferent therapeutic protocols available.

In Section 2 we will briefly state the prob-lem of revising therapy in IDDM monitoring.Section 3 will describe the protocol-basedreasoning process exploited by the MU, whileSection 4 will show an example of the reason-ing capabilities of the system, as implementedwithin the MU on a real clinical case.

2. T-IDDM monitoring of an IDDM patient

In current medical practice, IDDM pa-tients report the results of their self-monitor-ing activities in hand-written diaries. Thediary is revised and a new therapeutic proto-col is defined only when a patient undergoesthe periodic control visit.

Within the T-IDDM system, we aim atproviding a telemedicine service that shouldimprove the quality and efficiency of theoverall monitoring/therapy revision process.Patients collect metabolic data together withinsulin and food intake information everyday, and store them in the PU data base.Whenever a problem occurs, they can sendan alarm and the data to the MU to get aquick response from the physician, otherwiseall the information will be sent every 7–10days. The physician will receive the data, andanalyze them through the tools provided bythe MU. She will get further informationfrom physical examination when the periodicvisit takes place (every 2 months or even lessfrequently, if the patient has a goodmetabolic control). As patients’ monitoringdata could be analyzed more than once every2 months, a therapy adjustment could beimmediately suggested in order to solve possi-ble alterations, thus avoiding more seriouscomplications. The quality of the IDDM pa-

tients monitoring should be hence improvedthrough a better metabolic control, with aquicker reaction against potential dangeroussituations, the efficiency of the overall moni-toring service should be increased by reduc-ing the accesses to the hospital as well as byoptimizing the patients’ visit schedule.

As described in [19–21], the decision sup-port functionalities of the MU are performedin three steps: (i) high-level metabolicparameters are extracted from the homemonitoring data (intelligent data analysis);(ii) the state of the patient is evaluated on thebasis of descriptors derived in the previousstep [21]; and (iii) a protocol revision is thensuggested, if needed. Therapy revision strat-egy will be presented in detail in Section 3, inthis section we will briefly describe the out-comes of phases (i) and (ii).

2.1. Data analysis

The data collected through home-monitor-ing contain limited information. The typicalPU data set stores BGL measurements, in-sulin dosages, hypoglycemic events, presenceof ketone in the urine and modifications ofdiet and physical exercise, with respect to thetypical patients’ life-style. All this data aretime-stamped, and acquired several times(from three to four) a day.

In order to allow a proper interpretation ofthe data, the 24 h daily period is subdividedinto a set of consecutive non-overlappingtime slices: breakfast; midmorning; lunch;midafternoon; dinner; bedtime; and night-time. These time slices are generated on thebasis of the information about the patient’slife-style, in particular meal times. Each da-tum is hence associated to a given time slice.

The MU exploits the information comingfrom the PU through a set of tools to visual-ize and to analyze collected data. The physi-cian is allowed to inspect all the available

Page 4: Protocol-based reasoning in diabetic patient management

S. Montani et al. / International Journal of Medical Informatics 53 (1999) 61–7764

time series, that is BGL, glycosuria, ke-tonuria, HbAlc and insulin intakes, or torestrict the set of information to be plotted todata belonging to a single time slice, or to agiven time interval from the beginning of themonitoring period. Moreover, a set of statis-tical methods have been implemented, suchas the extraction of the daily average value ofBGL, the daily insulin requirement, and thenumber of serious hypoglycemic events in agiven period of time.

The MU also exploits some data character-istics derived by grouping them into series ofabstract episodes. In particular an abstractdescription of the course of longitudinal datais obtained through the temporal abstractions(TA) technique.

The basic principle of TA methods is tomove from a time-point to an interval-basedrepresentation of the data. Given a sequenceof time stamped data (events), the adjacentobservations which follow meaningful pat-terns are aggregated into intervals (episodes).In particular, an ontology which distin-guishes two main classes of abstractions hasbeen defined, BASIC abstractions for detect-ing predefined patterns in a univariate timeseries, and COMPLEX abstractions, for dis-covering specific temporal relationships be-tween episodes as well as for analyzingmultivariate patterns [20].

In particular, BASIC abstractions extractSTATES (e.g. low, normal, high values) orTRENDS (increase, decrease or stationaritypatterns) from a uni-dimensional time series.COMPLEX abstractions search for specifictemporal relationships between episodeswhich can be generated from a basic abstrac-tion or from other complex abstractions. Therelation between intervals can be any of thetemporal relations defined by Allen [22]. Thiskind of TA can be exploited to extract multi-dimensional patterns or to detect uni-dimen-sional patterns of complex shapes. Some

examples of the use of both BASIC andCOMPLEX abstractions are reported in [18].

The reasoning activity of the MU is basedon a careful analysis of STATE abstractions.When detecting STATE patterns in time se-ries of numerical variables, a preliminaryqualitative abstraction is carried out [20]. Themapping between the qualitative abstractionsand the quantitative levels of each numericalvariable depends on the time slice and on thespecific patient’s characteristics. For example,the BGL normal range is wider in the morn-ing than around lunch, and it is wider inpediatric patients than in adult ones. Then,the BGL state abstractions are derived, mov-ing from the original time scale to a new scaleobtained from the sequence of relevant pat-terns detected in the data.

After having identified the most significantepisodes, the Blood Glucose-Modal Day(BG-MD) can be extracted. It represents acharacteristic daily BGL pattern that summa-rizes the typical patient’s response to thetherapy in a specific monitoring period, it isusually derived as the collection of the mostprobable BGL qualitative level in each timeslice. The BG-MD is used to evaluate theprotocol performance over the selected timeinterval, even when the information is poor(e.g. data on meals missing). Several ap-proaches for extracting the BG-MD havebeen presented in the literature, from simplestatistics to time series analysis [23,3].

In our approach we derive the BG-MD bycalculating the marginal probability distribu-tion of the BGL STATE abstractions. Inparticular, we apply a Bayesian method de-scribed in [24] that is able to explicitly takeinto account the presence of missing data.

Five BGL state TAs are considered, Se-vere hypoglycemia, Hypoglycemia, Normo-glycemia, Hyperglycemia, Severe hyper-glycemia. Before starting data collection in agiven period we may assign a prior probabil-

Page 5: Protocol-based reasoning in diabetic patient management

S. Montani et al. / International Journal of Medical Informatics 53 (1999) 61–77 65

ity to the occurrence of each state TA equalto 1/5. After a certain monitoring period of Ndays, we collect D measurements, while theremaining M=N−D data are missing. Theposterior probability bounds of the occur-rence of a generic k-th of the five levels, givenby difference between the upper (psup) and thelower (pinf) probability bound, can be derivedas:

pinf=1+dk

5+N

psup=1+dk+M

5+N

where dk is the number of occurrences of thek-th level in the monitoring period.

The difference between psup and pinf is pro-portional to the number of missing data andis denoted as the ignorance in the monitoringperiod.

As the monitoring process proceeds, thebounds on the probabilities are updated. Atany time we obtain, for each time slice, aninterval probability distribution over theBGL state abstractions. The modal day isextracted by taking the BGL states with thehighest pinf in each time slice.

By using the same procedure it is possibleto extract the posterior distribution for eachmonitoring variable. For example, useful in-dicators are given by the glycosuria and in-sulin MD.

Once the modal days have been derived,the MU is ready to carry out the protocol-based reasoning task that will be described inthe next section.

3. Protocol-based reasoning

In IDDM management the physician musthandle the complex task of revising and as-signing therapeutic protocols to a (usually)

large number of patients, according with theterminology adopted by physicians, we definea therapeutic protocol as a collection of fourplans, regarding insulin injections, diet, phys-ical exercise and control law (see next sectionfor details).

In a system for automatic protocol revi-sion, this reasoning activity can be imple-mented through the Episodic SkeletalPlanning Method (ESPM) [25]. ESPM hasbeen designed for domains with time-varyingdata, and in which actions have a time dura-tion [26]. It has been successfully used in anumber of medical applications, like T-HELPER [27]. The ESPM assumes the exis-tence of a skeletal plan, (in the IDDMcontext, a therapeutic protocol), which in-volves a set of constituent subplans that areeach more detailed than the abstract one (e.g.the insulin plan with the prescribed dosages).Subplans attributes have to be specified at aparticular time, depending on the currentclinical situation and on additional domainknowledge. The goal of our implementationof ESPM is to provide the patients with aprotocol able to solve their metabolic prob-lems, by revising and adjusting that they werefollowing since the latest revision. Themethod is said to be episodic as it is invokedseveral times: in fact, therapy is revised atleast at every patient’s visit, on the basis ofthe monitoring data, and possibly also atadditional time instants, throughteleconsultation.

Every time, the planner analyses patient’sdata and the therapeutic actions that are stillin progress, and suggests an appropriate ther-apy by refining an abstract, skeletal plan. TheESPM application leads to the full specifica-tion of a therapeutic protocol to be appliedto the patient at hand, in the current periodof time. In our system, the ESPM is struc-tured in two subtasks: (1) identifying prob-lems; and (2) modifying protocols.

Page 6: Protocol-based reasoning in diabetic patient management

S. Montani et al. / International Journal of Medical Informatics 53 (1999) 61–7766

Step (1). Identifies the features of the cur-rent situation that might require a modifica-tion in the therapeutic approach. This task isexecuted by first summarizing the indicatorsderived in the data analysis phase, as wasdescribed in the previous section, by calculat-ing the BGL, glycosuria and insulin MD.They then trigger a rule-based reasoning sys-tem able to extract the relevant problems(e.g. presence of hyperglycemia or hypo-glycemia in at least one time slice of theBG-MD) in the monitoring period.

Step (2). Aims at modifying the currentprotocol in order to tackle the identifiedproblems.

In the following sections, we will focus ourattention mainly on Step (2) of our imple-mentation of the ESPM.

3.1. The protocol ontology

The therapeutic protocols defined in theontology we developed (see Fig. 1) are theskeletal plans to which ESPM is applied, theyjust depict the generic structure of a thera-peutic protocol, but the values of the at-tributes of the planning entities (i.e. theinsulin doses or the caloric intake) are notspecified at this level, and will be calculated

by developing the reasoning process in anyspecific case. A protocol can be hierarchicallydecomposed into a set of four plans, summa-rizing the different actions to be carried out.� Insulin plan: it indicates the number of

insulin units to be injected daily (distin-guishing regular, NPH and eventually pre-mixed insulin), and their distribution atthe different time slices of the day.

� Diet plan: it defines the suggested caloricintakes and their distribution amonglipids, proteins and carbohydrates overmeals and snacks.

� Exercise plan (optional): it indicates howmuch the regular insulin dose should bereduced after some physical exercise.

� Control law: it defines the insulin require-ment and the diet adjustments on the basisof the patient’s age, weight, and bloodglucose measurements just beforeinjections.The diet plan, the exercise plan and the

control law have to be intended as ‘adjust-ments’ of the prescribed therapy, directly ap-plicable by the patients in dependence oftheir health status and of occasional life-stylemodifications. Only if the symptoms persist, areal therapeutic revision will be required, onsuch situations, the automatic reasoner willbe invoked, and will produce suggestions re-garding the insulin plan.

At a deeper level of detail, an insulin planis defined by a set of attributes, that refer tothe insulin intake at each time slice. The timeslices in which insulin can be injected are five:the three meal time slices (breakfast, lunchand dinner), bedtime and midafternoon. Ac-cording to the distribution of insulin intakeover the day, three classes of insulin planscan be identified:� The two injection plans, in which insulin is

given only at breakfast and at dinner.� The three injection plans, in which an

extra dose of regular insulin is inserted atlunch or at midafternoon.Fig. 1. Plan components.

Page 7: Protocol-based reasoning in diabetic patient management

S. Montani et al. / International Journal of Medical Informatics 53 (1999) 61–77 67

� The four injection plans, in which everymeal is compensated by insulin, and anextra dose is given at bedtime, to avoidhyperglycemia at night.Below is shown an example of a three

injection insulin plan.

SAMPLE–INSULIN–PLAN‘10-16-1997CREATION–TIME11:54:53’

AUTHOR ‘Dr. Lorini’1PATIENT–ID3INJECTIONS–NUMBER

BREAKFAST–NPH 0.60BREAKFAST–PREMIXED

BREAKFAST–REGULAR 0.030LUNCH–NPH0LUNCH–PREMIXED0.1LUNCH–REGULAR0MIDAFTERNOON–NPH

MIDAFTERNOON 0

–PREMIXEDMIDAFTERNOON 0

–REGULARDINNER–NPH 0.24DINNER–PREMIXED 0

0.03DINNER–REGULAR0BEDTIME–NPH0BEDTIME–PREMIXED

BEDTIME–REGULAR 0‘Actrapid’REGULAR INSULIN TYPE‘Monotard’NPH INSULIN TYPE‘Arm’INJECTION SITE

The protocol ontology defines the structureof the therapeutic protocols, as it has beendescribed above. Each protocol is given bythe composition of the instances of the plansfor insulin, meal, physical exercise and con-trol law. The collection of such instancescomposes the protocol library, that containsthe most frequently recommended protocol inclinical practice.

The reasoner first proposes its own solu-tion to the metabolic alterations, by fullyspecifying the attributes of a skeletal plan,suitable for the patient’s life style. Then, itidentifies the additional library protocols thatcould face the metabolic problems, and liststhem as alternative solutions to its first re-sponse. Therefore the physician can chooseamong a set of suggestions, listed togetherwith an indication of their degree of suitabil-ity, deduced from their differences from theprotocol adopted in the previous period.

3.2. Situation-based re6ision

The therapy advisor is implementedthrough a rule-based system, whose tasks aresummarized in Fig. 2. After having analyzedthe monitoring data, the advisor generates aset of suggestions, identifies the most suitableones for the patient at hand, and appliesthem to the current insulin plan in order totackle the metabolic alterations.

The medical knowledge needed to selecttherapeutic actions is represented throughproduction rules, organized in a taxonomy ofclasses/subclasses. The main classes are de-scribed below.� Suggestion rules: each rule in this set has

a premise which is satisfied when a certainmetabolic problem is detected. A more de-tailed description of the rule class is given inFig. 3. Rules are divided into subclasses onthe basis of the advice they generate: a spe-cific problem might be solved by adjustingthe insulin doses, or by revising the diet, orthe physical exercise plan. Therefore, everytime more than one rule fires, so obtaining aset of alternative solutions to be furtherevaluated.

Patients and physicians are asked to fill ina form concerning their preferences about thetypes of actions to be applied to the thera-peutic protocol. Five are the possible actions

Page 8: Protocol-based reasoning in diabetic patient management

S. Montani et al. / International Journal of Medical Informatics 53 (1999) 61–7768

Fig. 2. Steps of the reasoning process towards protocolrevision.

where IA(t) is the residual insulin activity attime t obtained as in Fig. 4, and P is thepreference assigned by the physician (or bythe patient) to that particular action. The IAis calculated using the model proposed byHovorka [29], and depends only on the spe-cific insulin type chosen for the patient athand.

Therefore, for example, a regular insulinadjustment at lunch would be suitable tosolve a problem in the afternoon, while anNPH adjustment in the evening would beapplicable to reach normoglycemia in themorning or during the night.

In a similar way we calculate the effective-ness of a given food intake, the score of ameal suggestion will then be high if the prob-lem to solve is present just after the meal timeslice. The food activity is calculated as in [30].

When a mild hyperglycemia and someepisodes of severe hypoglycemia occur in thesame time period, the system, in accordancewith the majority of physicians, considershypoglycemia as a higher risk condition, andgenerates advice to compensate it.

At the end of the suggestion generationstep, the advice set is shown, together withthe metabolic problem that originated it.

The following text provides an example ofa suggestion rule: it faces a hypoglycemiaproblem by suggesting to decrease NPH in-sulin in all the preceding time slices.

IF X IS A PROBLEMAND THE BGL QUALITATIVE LEVELOF X IS LOWAND THE MINIMUM PROBABILITYOF X \=0.1AND THE TIME SLICE OF X IS YAND THE NPH INSULIN ACTIVITYIN THE Y TIME SLICE IS IAAND THE NPH PREFERENCE IS PTHEN DECREASE NPH DOSE IN YAND ASSIGN A SCORE OF IA*P TOTHIS SUGGESTION

to be carried out: nph or regular insulindosage adjustments, and meal, snack or phys-ical exercise corrections. They have to beordered from the most to the less suitable forthe patient at hand. Then they are reportedon a scale from 0 to 1 [28] and finally a scoreis calculated for each admissible solution, onthe basis of the preferences and of a forecast-ing of its effectiveness.

When referring to insulin doses, effective-ness is related to insulin activity. The scorefor an insulin suggestion, concerning an in-sulin dose given at time 0 and calculated withrespect of its effect at time t is hence:

S=IA(t)×P (1)

Page 9: Protocol-based reasoning in diabetic patient management

S. Montani et al. / International Journal of Medical Informatics 53 (1999) 61–77 69

Fig. 3. Taxonomy of the suggestion rules.

� Temporal rules: not all the suggestionsgenerated in the previous step may be appli-cable to the patient at hand; indications haveto fit the patient’s life style and the physi-cian’s opinions about the most suitable ther-apy modifications.

As an example, the following rule deletesall the suggestions concerning NPH insulin,to be applied in a time slice in which no NPHinsulin can be injected.

IF X IS A NPH SUGGESTIONAND THE TIME SLICE OF X IS

Page 10: Protocol-based reasoning in diabetic patient management

S. Montani et al. / International Journal of Medical Informatics 53 (1999) 61–7770

Fig. 4. Insulin activities.

NIGHTTIME OR MIDMORNING ORMIDAFTERNOON THEN DELETE X� Combination rules: even after the dele-

tion of suggestions that resulted to be notadmissible for the patient at hand, it is neces-sary to filter the remaining ones in order tocarry out just one action in a single time slice.In fact, more than one correction on thetherapy scheme could result in a too strongintervention, and might generate thereforenew metabolic alterations.

At the end of this step, the remainingadvice is presented to the physician, in orderto let her understand what kind of adjust-ments will finally be applied to the currenttherapy scheme.

The following rule executes the filteringtask:

IF X AND Y ARE SUGGESTIONAND X IS NOT YAND THE TIME SLICE OF X IS THE

TIME SLICE OF YTHENSELECT THE SUGGESTION WITHTHE HIGHER SCORE� Insulin plan rules: all the remaining sug-

gestions related to insulin adjustments areapplied to the current insulin plan. If theinsulin requirement has to be kept constant,when a correction in the insulin dose is per-formed in a time slice (corrections are alwaysa 10% increase or decrease), another correc-tion of the opposite sign is made in someother slices, so that the daily insulin intake iskept unchanged. Moreover, all the insulinplans stored in the data base are analyzed,and all the ones suitable for the patient athand are listed. For each of them, the ‘dis-tance’ from the current plan is calculated, byapplying the Euclidean distance formula (2)on the insulin doses in the various time slices.For each current-new plan pair we calculate

Page 11: Protocol-based reasoning in diabetic patient management

S. Montani et al. / International Journal of Medical Informatics 53 (1999) 61–77 71� %n

i=1(regi

cp−reginp)2+ (nphi

cp−nphinp)2�1/2

(2)

over n=5 time slices, where regicp, regi

np de-note the dose of regular insulin in the i-thtime slice given in the current and in the newplan, respectively, the same notation holdsfor NPH insulin. Finally, the selected plansare ordered on the basis of distance and maybe easily adapted when premixed insulin isused.

The final choice is left to the physician,who can select one of the suggested plans oredit a new plan: she could get further infor-mation from the physical examination of thepatient, and therefore conclude that a correc-tion based only on the analysis of the BGL,glycosuria and ketonuria modal day wouldnot lead to a definitive solution.

Moreover, advice regarding meals andphysical activity can be used by the patient,under the physician’s supervision, to makeadjustments to either the diet or the exerciseplan.

The following rule is an example of how toperform NPH insulin adjustments on theplan doses.

IF X IS A NPH SUGGESTIONAND THE TIME SLICE OF X IS YAND INSULIN PLAN OF THE CUR-RENT PROTOCOL IS WTHENADJUST W BY APPLYING X IN THETIME SLICE Y

4. Implementation

The system is implemented as a distributedenvironment, composed of a set of MU ser-vices and an integrated PU service. The basicstructure of the system is shown in Fig. 5.

The PU and MU services cooperate usinga common communication protocol and a

shared domain ontology describing the struc-ture of the information circulating within thesystem.

The heart of the distributed architecture isLISPWEB [31], a World Wide Web (WWW)server written in Common Lisp, able to guar-antee the automatic generation of HTMLpages and the communication among the sys-tem components through an extended versionof the HTTP protocol, called STSP. TheHTTP protocol, that is the protocol on whichthe WWW is based, is oriented toward theexchange of request-response messages typi-cal of client-server architectures. The STSPprotocol, on the other hand, makes it possi-ble to carry out more complex forms of nego-tiation and dialogue. LISPWEB convertsrequests made by the patient or by the physi-cian into calls to the different servers of thesystem, and uses the results to write HTMLpages, containing dynamically generated in-formation, shown in different forms, such asmulticolumn tables or plots. The choice ofJAVA language has enabled the implementa-tion of animation techniques, useful to visu-alize all the monitoring data in a single plot,and to immediately identify all the relevant

Fig. 5. Functional view of the system modules.

Page 12: Protocol-based reasoning in diabetic patient management

S. Montani et al. / International Journal of Medical Informatics 53 (1999) 61–7772

alterations of a given patient. The use of anextensible and dynamical server such asLISPWEB allows the development of kindsof interaction that can be very complex, butthat in the same time are completely trans-parent to the user, who just has to learn howto use a common web-browser, a kind ofprogram today widely diffuse and quiteinexpensive.

5. The system at work

An overview of our system’s capability,and in particular of the therapy advisor, canbe obtained considering a real clinical case:our sample patient is a boy of the age of 19,whose diabetes onset took place in 1991. Wewill focus our attention on a period of 2months, the typical time interval between twovisits. In the month of March 1997, the pa-tient was assigned a three injections plan, inwhich the daily insulin intake was subdividedinto the following percentages:� 48% of NPH+8% of regular at breakfast.� 100% units of 50/50 premixed insulin (i.e.

5% units of NPH+5% units of regular atlunch).

� 34% units of NPH at dinner.for a total daily insulin requirement of 0.7U/kg.

Automatic revision of the therapy was per-formed on the basis of the data collected inthe period March–May 1997.

5.1. Data collection

During the visit, on the beginning of thesample period (12 March), the physiciansaved in the data-base all the informationconcerning weight (78.6 kg), HbAlc (8.3%),and results of a physical examination. On thebasis of these data the already described in-sulin plan was chosen, together with a diet of

2805 kcal/day. From that moment on, for thefollowing two months, the boy collected hisBGL, glycosuria and ketonuria data in thePU data-base, and contacted the MU only tocommunicate alarms or messages, when hehad problems of bad glycemic control (forexample, hypoglycemia after physical exer-cise: he was suggested to have a snack in theafternoon on the activity days).

5.2. Data analysis

On 21 May, the data received from the PUwere analyzed through the data abstractionserver, in order to extract the possible prob-lems and therefore to revise therapy. TheMD computation identified episodes of bothmild and severe hypoglycemia at dinner (seeFig. 6), and of severe hypoglycemia at break-fast and at bedtime; as can be easily seen forthe ‘BGL normal’ abstraction (the one in themiddle), the maximum and the minimumprobability associated to the qualitative valuediffered for a quantity, visible as a light greybar on the top of the dark grey column: suchquantity represents the ignorance that affectsthe data, depending on the fact the patientdid not always record his BGL values. Any-way the minimum probability of hypo-glycemia was always over 10%, a levelalready considered at risk by the physicians.Instead, hyperglycemia did not reach theprobability of 39%, and ignorance was above15%, it did not represent a dangerous condi-tion, again in accordance with the physicians’general opinion.

5.3. Automatic protocol re6ision

Before prescribing a new therapy schemeto the patient, in order to tackle hismetabolic control problems, the physicianasked the therapy advisor to provide somesuggestions for choosing the protocol for the

Page 13: Protocol-based reasoning in diabetic patient management

S. Montani et al. / International Journal of Medical Informatics 53 (1999) 61–77 73

Fig. 6. The patient’s BGL modal day at dinner.

following period. Before the reasoning pro-cess was started, she had to fill in a formconcerning her preferences about the possiblecorrective actions to be applied, and whetherto modify the daily insulin requirement: thereasoner is meant to be used by the physicianin an interactive way.

The reasoning process executed the follow-ing phases:

� Advice generation: each detected prob-lem could be solved by a series of actions (seeFig. 7), in particular, bedtime severe hypo-glycemia might be avoided by an increase infood intake at dinner, or otherwise by a

reduced dose of NPH insulin at lunch, atdinner, or at breakfast. The low score of thebreakfast suggestion is due to the reductionin insulin activity during the all day. Theadvisor also suggests to reduce the regularinsulin dose at dinner, but it was not applica-ble to the plan at hand, as regular insulininjections were scheduled only at breakfastand at lunch.

Hypoglycemia at dinner might be foughtby decreasing NPH insulin at breakfast or atlunch, or by decreasing regular insulin atlunch (if a regular dose at midafternoon wasscheduled, it should be reduced).

Page 14: Protocol-based reasoning in diabetic patient management

S. Montani et al. / International Journal of Medical Informatics 53 (1999) 61–7774

Fig. 7. All the suggestions generated by the system.

dinner (or at bedtime, if there was one).� Advice selection: on the basis of the

physician’s preferences, of the patient’s lifestyle and of insulin activity during the day, asmaller set of suggestions was selected. It wasproposed to reduce the percentage of NPHinsulin at breakfast and at lunch, while thehypoglycemia problem at bedtime would besolved by increasing the food intake at din-ner, as this adjustment was more effectivethan an insulin reduction in the same timeslice: in fact the patient only assumed NPHinsulin at dinner, and the NPH activity atbedtime was quite small, therefore the scoreassigned to the NPH reduction suggestionwas lower than the one of the meal increase.The insulin plan did not contain a regulardose at midafternoon or an NPH dose atbedtime: the suggestions concerning thesetime slices could not be applied (see Fig. 8).� Plan revision: the reasoner first calcu-

lated a possible insulin plan that was a ma-nipulation of the current one, in which the

Finally breakfast hypoglycemia could befought by reducing the regular insulin dose at

Fig. 8. The advice generated for the patient at hand.

Page 15: Protocol-based reasoning in diabetic patient management

S. Montani et al. / International Journal of Medical Informatics 53 (1999) 61–77 75

Fig. 9. The most strongly recommended plan among the ones selected by the system.

breakfast NPH insulin percentage was reducedby 10%. Then it found all the library plans thatfollowed the selected advice, and weretherefore suitable to solve the currentproblems. Finally it ordered them byminimizing the difference in the insulin dosesin the various time slices. The physician chosethe most strongly recommended plan (see Fig.9), and just made a couple of adjustmentsbefore assigning it to the boy: she did not onlydecrease the NPH lunch insulin dose but alsothe regular one, in order to let the patient stilluse a 50/50 premixed insulin; moreover shepreferred to decrease the NPH insulin dose,instead of increasing the food intake at dinner.

6. Conclusions

In this paper, we have described theprotocol-based reasoning features of a system

for the management of IDDM patients. Thesystem we have implemented provides patientswith an instrument that gives them support fordata collection and teleconsultation. On theother hand, it supplies to physicians a set oftools able to visualize and analyze the patients’monitoring data, in order to detect eventualmetabolic problems, if any alterations havebeen identified, the protocol-based reasoner,realized through the ESPM, adjusts thetherapy to tackle them, in accordance with thepatients’ needs.

A central role has been reserved to thecare-provider, and her opportunities ofinteraction with the reasoner will increase inthe extensions we are working on. At the mostgeneral level, the physician will be able todecide whether to use the already implementedprotocol-based reasoning tool, or a case-basedone, according to which the most stronglyrecommended protocols would be the ones

Page 16: Protocol-based reasoning in diabetic patient management

S. Montani et al. / International Journal of Medical Informatics 53 (1999) 61–7776

that solved similar problems when applied toa large number of patients. Moreover, thephysician will be able to choose the metricsto order protocols, or what kind of statisticalanalysis (in addition to the modal day com-putation) have to be carried out on the pa-tient’s data, thus supplying a different inputto the reasoner and activating different setsof rules. The system is being developedwithin a 3-year project, started in June 1996.The verification phase of the project will startby the end of the year, and it will be carriedout by testing the services on a group of tenpatients chosen in the pediatric departmentof the San Matteo hospital in Pavia.

Acknowledgements

This work was supported in part by theT-IDDM project (HC-1047), funded by theEU with the Health Care TelematicsProgramme.

References

[1] The Diabetes Control and Complication Trial Re-search Group, The effect of intensive treatment ofdiabetes on the development and progression oflong-term complications in insulin-dependent dia-betes mellitus, New Engl. J. Med. 329 (1993) 977–986.

[2] E.D. Lehmann, T. Deutsch, Application of com-puters in diabetes care—a review I and II, Med.Inform. 20 (1995) 281–329.

[3] T. Deutsch, E.D. Lehmann, E.R. Carson, A.V.Roudsari, K.D. Hopkins, P.H. Sonksen, Time se-ries analysis and control of blood glucose levels indiabetic patients, Comput. Methods Prog. Biomed.41 (1994) 167–182.

[4] J. Skyler, D. Skyler, D. Seigler, M.O. Sullivan,Algorithms for adjustment of insulin dosage bypatients who monitor Blood Glucose, DiabetesCare 4 (1981) 311–318.

[5] A. Schiffrin, M. Mihic, B.S. Leibel, A.M. Albisser,Computer assisted insulin dosage adjustment, Dia-

betes Care 8 (1985) 545–552.[6] J. Beyer, J. Schrezenmeir, G. Schulz, T. Strack, E.

Kustner, G. Shulz, The influence of different gen-erations of computer algorithms on diabetes con-trol, Comput. Methods Prog. Biomed. 32 (1990)225–232.

[7] R.R. Holman, A.D. Smale, E. Pemberton, A.Riefflin, J.L. Nealon, Randomized controlled pilottrial of hand-held patient-oriented, insulin regimenoptimizer, Med. Inform. 21 (1996) 317–326.

[8] S. Andreassen, J. Benn, R. Hovorka, K.G. Olesen,E.R. Carson, A probabilistic approach to glucoseprediction and insulin dose adjustment: descriptionof metabolic model and pilot evaluation study,Comput. Methods Prog. Biomed. 41 (1994) 153–165.

[9] D.R.L. Worthington, Controlling blood glucose:Insights from an engineering control systems per-spective, Med. Inform. 22 (1997) 5–19.

[10] G. Zahlmann, M. Franczykiva, G. Henning, M.Strube, I. Huttls, I. Hummel, W. Bruns, DIABE-TEX—a decision support system for therapy oftype I diabetic patients, Comput. Methods Prog.Biomed. 32 (1990) 297–301.

[11] E.D. Lehmann, T. Deutsch, E.R. Carson, P.H.Sonksen, Combining rule-based reasoning andmathematical modeling in diabetes care, Artif. In-tell. Med. 6 (1994) 137–160.

[12] T. Deutsch, A.V. Roudsari, H.J. Leicester, T.Theodorou, E.R. Carson, P.H. Sonksen, UTOPIA:a consultation system for visit-by-visit diabetesmanagement, Med. Inform. 21 (1996) 345–358.

[13] M.A. Musen, Dimensions of knowledge sharingand reuse, Comput. Biomed. Res. 25 (1992) 435–467.

[14] E.J. Gomez, F. Del Pozo, M.E. Hernando,Telemedicine for diabetes care: the DIABTel ap-proach towards diabetes telecare, Med. Inform. 21(1996) 283–295.

[15] A.M. Albisser, R.I. Harris, S. Sakkal, I.D. Parson,S.C. En Chao, Diabetes intervention in the infor-mation age, Med. Inform. 21 (1996) 297–316.

[16] R. Bellazzi, C. Cobelli, E.J. Gomez, M. Stefanelli,The T-IDDM project: telematic management ofinsulin dependent diabetes mellitus. In: M.Bracale, F. Denoth (Eds.), Proceedings of HealthTelematics ‘95, Ischia, Italia (1995) pp. 271–276.

[17] R. Bellazzi, C. Siviero, M. Stefanelli, G. De Nico-lao, Adaptive controllers for intelligent monitor-ing, Artif. Intell. Med. 7 (1995) 515–540.

[18] R. Bellazzi, C. Larizza, A. Riva, Cooperative intel-ligent data analysis: an application to diabetic

Page 17: Protocol-based reasoning in diabetic patient management

S. Montani et al. / International Journal of Medical Informatics 53 (1999) 61–77 77

patients management, in: N. Lavrac, E. Keravnou,B. Zupan (Eds.), Intelligent Data Analysis inMedicine and Pharmacology, Kluwer, Dordrecht,1997.

[19] A. Riva, R. Bellazzi, High level control strategiesfor diabetes therapy, in: P. Barahona, M. Ste-fanelli, J. Wyatt (Eds.), Lecture Notes in ArtificialIntelligence, Springer, Berlin, 1995, pp. 185–196.

[20] C. Larizza, R. Bellazzi, A. Riva, Temporal ab-stractions for diabetic patients management, in: E.Keravnou, C. Garbay, R. Baud, J. Wyatt (Eds.),Lecture Notes in Artificial Intelligence, Springer,Berlin, 1997, pp. 319–330.

[21] R. Bellazzi, C. Larizza, A. Riva, Interpreting lon-gitudinal data through temporal abstractions: anapplication to diabetic patients monitoring, in: X.Liu, P. Cohen, M. Berthold (Eds.), Advances InIntelligent Data Analysis, Lecture Notes in Com-puter Science, Springer, Berlin, 1997, pp. 287–298.

[22] J.F. Allen, Towards a general theory of action andtime, Artif. Intell. 23 (1984) 123–154.

[23] M.G. Kahn, C.A. Abrams, M.J. Orland, J.C.Beard, S.B. Cousin, J.P. Miller, J.V. Santiago,Intelligent computer-based interpretation andgraphical presentation of self-monitored blood glu-cose and insulin data, Diab. Nutr. Metab. 4 (1991)99–107.

[24] M. Ramoni, P. Sebastiani, The use of exogenousknowledge to learn Bayesian Networks for incom-plete databases, in: X. Liu, P. Cohen, M. Berthold(Eds.), Advances In Intelligent Data Analysis, Lec-

ture Notes in Computer Science, Springer, Berlin,1997, pp. 537–548.

[25] S.W. Tu, H. Eriksson, J. Gennari, Y. Shahar,M.A. Musen, Ontology-based configuration ofproblem-solving methods and generation ofknowledge acquisition tools: application ofPROTEGE II to protocol-based decision support,Artif. Intell. Med. 7 (1994) 257–289.

[26] P.E. Friedland, Y. Iwasaki, The concept and im-plementation of skeletal plans, J. Auto. Reason. 1(1985) 161–208.

[27] M.A. Musen, R.W. Carlson, L.M. Fagan, S.C.Deresinsky, E.H. Shortliffe, THELPER: auto-mated support for community-based clinical re-search, In: Proceedings of the Sixteenth AnnualSymposium on Computer Applications in MedicalCare, Baltimore MD, 1992, pp. 719–723.

[28] I. McDowell, C. Newell, Measuring health. Aguide to rating scales and questionnaires, 2, Ox-ford University Press, London, 1996.

[29] R. Hovorka, S. Svacina, E.R. Carson, C.D.Williams, P.H. Sonksen, A consultation system forinsulin therapy, Comput. Methods Prog. Biomed.32 (1996) 303–310.

[30] E.D. Lehmann, T. Deutsch, A physiological modelof glucose-insulin interaction in type 1 diabetesmellitus, J. Biomed. Eng. 14 (1992) 235–242.

[31] A. Riva, R. Bellazzi, M. Stefanelli, A web-basedsystem for the intelligent management of diabeticpatients, MD Comput. 14 (1997) 360–364.

.