An HL7-Aware Multi-agent System for Efficiently Handling Query Answering in an e-Health Context Pasquale De Meo, Gabriele Di Quarto, Giovanni Quattrone, and Domenico Ursino DIMET, Universit` a Mediterranea di Reggio Calabria, Via Graziella, Localit` a Feo di Vito, 89060 Reggio Calabria, Italy
[email protected],
[email protected],
[email protected],
[email protected]
Abstract. In this paper we present a multi-agent system aiming at supporting patients to search health care services of their interest in an e-health scenario. The proposed system is HL7-aware in that it represents both patient and service information according to the directives of HL7, the information management standard adopted in medical context. In this paper we illustrate the technical characteristics of our system and we present a comparison between it and other related systems already proposed in the literature.
1
Introduction
Most industrialized countries are shifting toward a knowledge-based economy in which knowledge and technology play a key role for supporting both productivity and economic growth. This transition is characterized by deep changes affecting the individual quality of life and requires that economic development keeps pace with social progress. In this scenario, it is possible to foresee a rising demand of ad-hoc social services shaped around citizen needs [6]. The application of Information and Communication Technologies on the whole range of health sector activities (also known as e-health) can simplify the access to health care services and can boost both their quality and their effectiveness. E-Health tools allow the construction of patient-centric Health Care Service Providers (hereafter, HCSP s), aiming at supporting patients to access healthrelated information, to prevent their possible diseases and to monitor their health status. These considerations justify the large amount of health-related information disseminated over the Web; as an example, European Commission has recently activated the EU-health portal that supplies information on 47 health topics and allows the access to more than 40000 trustworthy data sources [7]. At the same time, individuals are showing a growing interest to health-related Web sites; as an example, a European Commission study observed that, in 2005, at least 33% of European adult population browsed the Web to search healthrelated information [7]. R. Meersman, Z. Tari et al. (Eds.): OTM 2006, LNCS 4275, pp. 967–974, 2006. c Springer-Verlag Berlin Heidelberg 2006
968
P. De Meo et al.
Despite the abundance of available proposals, the retrieve of interesting services is not always easy. In fact, existing HCSP s often use proprietary formats for representing data and services; as a consequence, their interoperability and comparison are generally difficult. In addition, the vocabulary exploited by a patient for composing his queries is often limited and consists of quite generic terms; on the contrary, medical resources and services are often described by means of specialistic terms. As a consequence, terms composing patient queries usually fail to match with documents describing medical resources and services. This might cause two, generally co-occurring, consequences. The former is that a query answer might contain a large number of useless proposals that fail to fulfill patient needs (false positives). The latter is that a query answer could ignore a large number of proposals that might be useful to the patient (false negatives). This paper focuses on these research issues and aims at providing a contribution in this setting; in fact, it proposes a multi-agent system for effectively supporting patients to detect health care services of their interest; the proposed system aims at coping with HCSP s interoperability and comparison problems, as well as at returning precise and complete results. Our system is HL7 aware; in fact, it uses the HL7 (Health Level Seven) standard [1] for effectively handling both service and patient information. HL7 provides several functionalities for the exchange, the management and the integration of data regarding both patients and health care services. It is strictly related with XML, since HL7-based documents can be easily coded in this language. Moreover, it is a widely accepted standard in the marketplace [8]; specifically, (i) a large number of commercial products implement and support it; (ii) several research projects adopt it as the reference format for representing clinical documents; (iii) various industrial and academical efforts have been performed for harmonizing it with other standards for the electronic representation of healthrelated data. HL7 plays a key role in our system since it allows interoperability and comparison problems to be successfully faced. Our system consists of five main components, namely: (i) a Patient Agent PA, allowing a patient to submit queries for detecting services of his interest; (ii) a Health Care Service Provider Agent - SPA, supporting a HCSP manager to maintain the corresponding service database up-to-date; (iii) a Coordinator Agent - CA, cooperating with PAs and SPAs to detect those services appearing to be the closest to patients’ queries and profiles; (iv) a Health Care Service Provider Database - SD, that is associated with a HCSP and manage information about services delivered by it; (v) a Patient Profile Database - PD, storing and handling patient profiles. Each time a patient submits a query, our system “intelligently” forwards it only to the most promising HCSP s, i.e., to those HCSP s providing services that are likely to best match both the submitted query and the patient profile. In order to guarantee this important feature, it implements three ad-hoc strategies, tailored to the peculiarities of our reference context. As it will be clear in the following, these strategies avoid a patient to manually contact and query a large number of HCSP s for retrieving services of his interest (this last activity is
An HL7-Aware Multi-agent System
Se Ins rvic e Re ertio Up mo n/ da val/ te
Se rv Inf ice o
Que
ice Serv fo In
, Pa ery
tien
t Pro
Qu
Coordinator Agent (CA)
ery , Pa
tien
t Pro
file
Se rv Info ice
file Pro nt te tie da Pa Up file Pro n nt tio tie c Pa xtra E
file Pro e t nt tie da Pa Up
Patient Agent (PA)
te da Up ile ry of Pr ue Q
te da Up file er y Pro Qu Patient Agent (PA)
Health Care Service Provider Agent (SPA)
file
ice Serv fo In
Patient
ry
Servic e Info
Qu
e rvic Se fo In
e rvic n/ Se ertio al/ Ins mov Re date Up
ice Serv n/ rtio Inse val/ o Rem ate Up d
Query Health Care Service Provider Agent (SPA)
Health Care Service Provider Manager
Health Care Service Provider Database (SD)
Health Care Service Provider Database (SD)
Se Ins rvic Re ertio e m n Up ova / da l/ te
Health Care Service Provider Manager
969
file Pro n io nt tie ct Pa Extra
Service Info
Patient Patient Profile Database (PD)
Service Info
Fig. 1. General architecture of our system
usually called Brute Force search in the literature) and allows those HCSP s that will more likely provide useful results to be preventively identified. As a consequence, patient queries are evaluated against a small number of HCSP s. This allows more precise and sound results to be achieved, as well as query execution time to be reduced, HCSP resource management to be improved and, finally, network performance to be increased.
2
Description of the Proposed System
The general architecture of our system is shown in Figure 1. From this figure it is possible to observe that our system is characterized by three typologies of agents, namely: (i) a Patient Agent (hereafter, P A), that supports a patient to search services of his interest; (ii) a Health Care Service Provider Agent (hereafter, SP A), that supports a HCSP manager to maintain the corresponding database up-to-date; (iii) a Coordinator Agent (hereafter, CA), that cooperates with P As and SP As to detect those services appearing to be the closest to patients’ exigencies and queries. In our system a HCSP is provided with a suitable database (hereafter, SD), storing and managing information about services delivered by it. Our system is also provided with a Patient Profile Database (hereafter, P D), storing and handling patient profiles. In the following we call SDSet (resp., SP ASet) the set of SDs (resp., SP As) associated with all involved HCSP s. 2.1
Health Care Service Provider Database (SD)
A HCSP Database is associated with a HCSP and stores information about the health care services delivered by it. The profile SPj of a health care service Sj consists of a tuple SIdj , SN amej , SDescrj , SU RLj , SF Sj , SCSj , where:
970
P. De Meo et al.
– SIdj , SN amej , SDescrj , SU RLj represent the code, the name, the description and the URL of Sj . – SF Sj = Fj1 , Fj2 , . . . , Fjp represents a set of features associated with Sj ; each feature is a keyword describing a peculiarity of Sj (e.g., an illness faced by it). As an example, consider the service “chest radiography”; a possible set of features describing it is {“pneumonia”, “heart failure”, “emphysema”, “lung cancer”, “check”, “radiography”}. – SCSj = SCj1 , SCj2 , . . . , SCjt is a set of constraints associated with Sj . A constraint SCjl consists of a pair SCN amelj , SCV alueslj , where SCN amelj represents its name and SCV alueslj indicates the corresponding admissible values. A constraint could represent the requisites a patient must have for accessing a certain service; another constraint could define the activation or the expiration date of a service, and so on. For instance, the constraint “free”, “Heart Problems”, associated with the service “Holter Monitoring”, might specify that if a patient has heart problems, then he is eligible for receiving Holter Monitoring service for free. SF Sj and SCSj are coded according to the rules specified for representing the component “entry” of the various sections of the Body of the Clinical Document Architecture (CDA), release 2. CDA is the HL7-based standard for representing clinical documents. These rules specify that section entries are represented with the support of specific dictionaries. CDA sections of interest for SF Sj are “Problem list”, “History of past illness”, “History of medication use”, “History of present illness”, “Family history”, “Social history”, “Immunization”, “Past surgical history”. CDA sections of interest for SCSj are: “Problem list”, “History of allergies”, “Past surgical history”, “Family history”, “Social history”, “Immunization”, “History of past illness”, “History of medication use”, “History of present illness”. All these sections refer to the LOINC [2] dictionary for their definition and to the SNOMED CT [3] dictionary for their content; however, if necessary, HL7 allows other dictionaries to be exploited. According to HL7 suggestions, for those features and/or constraints that cannot be coded by means of the already defined sections and the already existing dictionaries, we have defined new specific sections and a new specific dictionary. SD is constructed and handled by means of the XML technology. 2.2
Patient Profile Database (P D)
P D stores the profiles of the patients involved in our system. A Patient Profile P Pi , associated with a patient Pi , consists of a triplet DSi , M Pi , P CSi , where: and the social data of Pi . – DSi stores both the demographic – M Pi = Ki1 , Ki2 , . . . , Kim represents the Medical Profile of Pi ; it consists of a set of keywords capable of representing both his pathologies and his possible needs in the health care domain. It is worth pointing out that M Pi is much more than a simple clinical document recording patient diseases. In fact, due to its mission, our system
An HL7-Aware Multi-agent System
971
should not restrict itself to record patient diseases but it should offer tools for providing patients and health care professionals with a profile-guided access to a large variety of health care related services, as well as for raising both the quality and the efficacy of the Public Health Care System. These goals can be achieved by managing patient information at a broader level than that guaranteed by a simple patient’s pathologies list. This choice agrees with the ideas outlined in [9,13], where it is pointed out that, besides medical information, the profile of a patient in e-health systems should include his tasks and goals, his cognitive and psychological peculiarities, and so on. – P CSi = P Ci1 , P Ci2 , . . . , P Cil is a set of constraints associated with Pi . A constraint P Cih is a pair P CN amehi , P CV alueshi, where P CN amehi represents its name and P CV alueshi indicates the corresponding admissible values. The exploitation of constraints allows a wide range of health-related episodes to be correctly managed. As an example, the constraint “allergen”, “penicillin”, associated with Pi , specifies that penicillin is an allergen for him. The relevance of this constraint is clear: it might prevent Pi from undergoing a clinical treatment involving penicillin. DSi is coded according to the rules specified for representing the component “Record Target” of the Header of the CDA, release 2. The fields of “Record Target” taken into account in DSi are: “Id”, “Name”, “Addr”, “Telecom”, “Administrative Gender Code”, “Birth Time”, “Marital Status” and “Living Arrangement”. According to HL7 philosophy, whenever necessary, we have defined and exploited other fields not already defined in HL7 standard (think, for example, to the field “patient yearly income”). M Pi and P CSi representations conform to the rules specified for representing the component “entry” of the various sections of the Body of the CDA, release 2. Reference sections and dictionaries are the same as those considered for SF Sj and SCSj . For those features and constraints that cannot be coded by means of the sections and the dictionaries already proposed for CDA and HL7 we have adopted the same sections and the same dictionary defined for SF Sj and SCSj . Analogously to SD, also P D is constructed and managed by means of the XML technology. 2.3
Patient Agent (P A)
A Patient Agent P Ai is associated with a patient Pi . Its support data structure stores the profile of Pi . P Ai is activated by Pi when he wants to know if there exist new services of interest for him and, in the affirmative case, for accessing them. First P Ai retrieves P Pi from P D and stores it in its support data structure. Then, it allows Pi to submit a query Qik specifying the service typology he presently desires. Qik consists of both a set of keywords QKSik = {Q1ik , Q2ik , . . . , Qrik } and a stop condition, stating when it can be considered satisfied (for instance, a stop condition might state that Qik can be considered satisfied if at least 10 services have been retrieved). After this, P Ai forwards the pair Qik , P Pi to CA which is in charge of processing it. When CA returns the corresponding results, P Ai presents them to Pi .
972
P. De Meo et al.
P Ai can be activated by Pi also when he wants to update his profile P Pi . In this case it retrieves the current P Pi from P D and shows it to Pi by means of a graphical interface. At this point Pi can modify it in a friendly and guided fashion. At the end of this activity P Ai stores the updated P Pi into P D. 2.4
Health Care Service Provider Agent (SP A)
SP A is an Interface Agent, analogous to that described in [5]. A SP A is associated with a HCSP that uses it for adding, modifying or removing information about the services it provides. SP A allows our system to uniformly manage possibly highly heterogeneous services. It is also in charge of processing queries submitted by CA; in this case, it retrieves the necessary information from its SD and processes it in such a way to construct the corresponding answers. 2.5
Coordinator Agent (CA)
CA receives a pair Qik , P Pi from a Patient Agent P Ai and processes Qik taking also into account information stored in P Pi . First it determines those SP As appearing to be the most adequate for answering Qik ; then, it requires each of them to process Qik ; after this, it merges provided results for constructing the final answer; finally, it sends this answer to P Ai that presents it to Pi . For selecting the most adequate SP As for a query, we have implemented three ad-hoc algorithms, called Patient Profile Based (PPB), Database Similarity & Patient Profile Based (DS-PPB) and A∗ -Based (AB). PPB relies on the general observation that combining query processing techniques with user profile information into a single framework allows the most adequate answers to user queries to be found [10]. DS-PPB considers not only information stored in patient profiles but also semantic similarities possibly existing among SDs. In our opinion, the knowledge of these similarities allows the enhancement of query processing activities and, consequently, the increase of the number of relevant services that the system can propose to a patient. The philosophy underlying AB is quite different from that underlying P P B and DS-P P B. In fact, these last can be considered “query-centric”, since they process a query at a time and determine the SP As best satisfying it. On the contrary, AB can be considered “provider-centric”, since it considers a set of queries QSet at a time and partitions it into disjoint subsets, each associated with a SP A of SP ASet; this enhances the overall “quality” of answers.
3
Related Works
In this section we compare our system with other ones aiming at supporting a user in his access to health care services. In [11] a system supporting a user to retrieve information of his interest in a medical context is proposed. It is possible to detect some similarities between our system and that described in [11]. Specifically, both of them: (i) provide a
An HL7-Aware Multi-agent System
973
suitable formalism for representing medical resources; (ii) provide a technique for determining the importance of each keyword composing a query. As for the main differences between them we observe that: (i) our system has been conceived to support mainly patients; on the contrary, the approach of [11] aims at supporting a wider range of users (e.g., patients, health professionals, etc.); (ii) the system of [11] does not take patient profiles into account; (iii) for performing its tasks, the system of [11] exploits a semantic network of medical terms whereas our system uses patient and service profiles. In [4] a multi-agent system aiming at supporting physicians to retrieve medical information is described. As for the main similarities between the system of [4] and ours, we observe that both of them: (i) are provided with a suitable data structure for modelling patient needs; (ii) are multi-agent; (iii) consider an intermediate agent capable of gathering results coming from different medical databases; (iv) manage a scenario in which autonomous and heterogeneous medical databases coexist. As for the main differences between them, we observe that: (i) the system of [4] has been conceived for supporting mainly physicians; (ii) the system of [4] requires a medical ontology for processing queries; on the contrary, our system exploits both patient and service profiles. In [12] PERSIVAL, a system for supporting physicians to search documents about patient care, is presented. PERSIVAL and our system are similar in that: (i) both of them use keywords for representing patient and service profiles; (ii) in both of them retrieval activity is driven by patient profiles. The main differences between them are the following: (i) the end users of PERSIVAL are physicians whereas the end users of our system are patients; (ii) PERSIVAL is provided with a summarization functionality; this is not present in our system; (iii) in PERSIVAL no notion someway analogous to our “Affinity” concept has been defined. In [9] MMA, a system for delivering medical information to an heterogeneous audience of users, is proposed. Our system and MMA share some similarities; specifically, both of them: (i) associate a suitable profile with each user; (ii) consider not only strictly medical data but also other information, such as demographic and social data. As for the main differences between them, we observe that: (i) in MMA user profiles are based on stereotypes whereas, in our system, each profile is specific for a patient; (ii) MMA takes a great care to the graphical interface characteristics desired by a user; this aspect is not considered by our system; (iii) MMA has been conceived for handling various user typologies whereas our system is specifically devoted to support patients.
4
Conclusions
In this paper we have presented an HL7-aware multi-agent system supporting patients in their access to services delivered by HCSP s. The proposed system combines submitted queries with the corresponding patient profiles for identifying those services that are likely to satisfy patient needs and desires. Various extensions and improvements might be thought for our system in the future. Among them we consider particularly challenging to investigate the
974
P. De Meo et al.
possibility to integrate our system with a Decision Support one; in this way, patient behaviour could be analyzed (for instance, by means of a Data Mining tool) for determining the key features of the most appreciated services. This information might be particularly useful for HCSP s managers when they must decide the new services to propose.
References 1. Health Level Seven (HL7). http://www.hl7.org. 2. Logical Observation Identifiers Names and Codes (LOINC). http://www.regenstrief.org/loinc/. 3. Systematized NOmenclature of MEDicine Clinical Terms (SNOMED CT). http://www.snomed.org. 4. L. Braun, F. Wiesman, J. van den Herik, and A. Hasman. Agent support in medical information retrieval. In Proc. of the IJCAI International Workshop on Agents Applied in Health Care, pages 16–25, Edinburgh, UK, 2005. 5. A. Cesta and D. D’Aloisi. Building interfaces as personal agents: a case study. ACM SIGCHI Bullettin, 28(3):108–113, 1996. 6. European Commission. e-Health - making healthcare better for European citizens: An action plan for a European e-Health Area. Technical report, Available at http://europa.eu.int/information society/doc/qualif/health/, 2004. 7. European Commission. Reliable health information at the click of a mouse European Commission launches new Health Portal. Technical report, Available at http://ec.europa.eu/health-eu/index en.htm, 2006. 8. M. Eichelberg, T. Aden, J. Riesmeier, A. Dogac, and G.B. Laleci. A survey and analysis of electronic healthcare record standards. ACM Computing Surveys, 37(4):277–315, 2005. 9. L. Francisco-Revilla and F.M. Shipman III. Adaptive medical information delivery combining user, task and situation models. In Proc. of the ACM International Conference on Intelligent User Interfaces (IUI’00), pages 94–97, New Orleans, Louisiana, USA, 2000. ACM Press. 10. G. Koutrika and Y. Ioannidis. Personalized queries under a generalized preference model. In Proc. of the IEEE International Conference on Data Engineering (ICDE 2005), pages 841–852, Tokyo, Japan, 2005. IEEE Computer Society Press. 11. Z. Liu and W.W. Chu. Knowledge-based query expansion to support scenariospecific retrieval of medical free text. In Proc. of the ACM Symposium on Applied Computing (SAC ’05), pages 1076–1083, Santa Fe, New Mexico, USA, 2005. ACM Press. 12. K.R. McKeown, N. Elhadad, and V. Hatzivassiloglou. Leveraging a common representation for personalized search and summarization in a medical digital library. In Proc. of the ACM/IEEE Joint Conference on Digital Libraries (JCDL ’03), pages 159–170, Houston, Texas, U.S.A., 2003. IEEE Computer Society. 13. E. Vasilyeva, M. Pechenizkiy, and S. Puuronen. Towards the framework of adaptive user interfaces for eHealth. In Proc. of the IEEE Symposium on Computer-Based Medical Systems (CBMS’05), pages 139–144, Dublin, Ireland, 2005. IEEE Computer Society.
