For the lay-person, free health information on the Web is a potentially valuable resource for better understanding personal symptoms, medical conditions, drugs, and nutrition. However, while sites such as WebMD [1] provide accredited sources of information, a multitude of other sources such as blogs, Wikipedia articles, and news articles exist that provide no guarantees about their completeness, accuracy, or objectivity. Thus, distinguishing between reliable and unreliable information is a central issue. However, even when restricted to verified sources, the sheer quantity of available material often makes meaningful interpretation a challenging task for readers without a medical background. For example, a study published by White and Horvitz in 2009 demonstrated a phenomenon known as “cyberchondria”, wherein a person experiences a heightened anxiety about medical conditions after reviewing search results and online literature relating to common symptoms (eg, headache [2]). Finally, the issue of “information quality” is both personal and subjective—information that is relevant for one individual might not be relevant to another, based on personal factors such as overall health, drug-regimen or other interventions, lifestyle, gender, or even personal interest. As observed by Burgess et al, “due to the unique nature of every individual, a single…method that assumes all people are the same will fail to meet every person’s information needs” [3]. It would be highly desirable, therefore, to assist Web users by filtering and/or annotating the information they encounter on the Web in a personalized way, thereby increasing its relevance and utility to that individual. Moreover, given that a patient may be at any point in their continuum-of-care, it would be particularly desirable to provide the patient’s clinical-care team an opportunity to include their “voice” into that annotation and filtering mechanism, such that the clinician’s plan for that patient enhances the personalization of the page even further.

We recently published a novel framework for automatically synthesizing contextually-sensitive data retrieval and analysis workflows composed of dynamically-selected Semantic Web Services [4]. The system used a semantic template describing the abstract “intent” of the workflow, combined with the specific details in a given dataset, to concretize an appropriate workflow capable of evaluating that data. In this work we intend to demonstrate, using a straightforward prototype application called the Semantic Automated Discovery and Integration (SADI) Personal Health Lens, that these components—the data, the semantic model, and the derived analytical workflow—map directly onto the various facets of the Health Web personalization problem described above. The Personal Health Lens application utilizes the patient’s individual medical history and data, the clinician’s plan for that patient (in the form of a semantic query), and publicly available tools that can be automatically selected and appropriately chained-together to analyze and contextually interpret the content of a webpage. The output is an annotated page containing new information specifically relevant to that patient, which is loaded into their browser as usual.

Personalization of Web information necessitates the use of the individual’s personal medical profile, since this information can be used to identify both relevant and inappropriate advice within a webpage. There has been considerable work in the area of semantic representation of electronic patient records, both institutional [5] and personal [6], and a variety of different standards exist for the content and structure of these records. Here, we do not intend to prescribe or proscribe any particular standard. This work simply assumes that such health records exist, are accessible to the local browser, and are (or can be) expressed in standard Semantic Web syntaxes. As the various models for electronic health records begin to consolidate, the prototype system could be easily re-written to conform to that standard. For the purposes of this prototype, we created a simple model of the drug-regime portion of the patient’s health record, along with several other clinical and personal features.

Much of the prior work in “personalization” of a patient’s Web experience has been in the domain of facilitated search, particularly through the use of semantically-backed personal health portals (eg, [3,7]) where the role of semantics in the portal is either for search-expansion to discover additional relevant pages, and/or to simplify medical terminology for the patient while still providing access to complex literature. While portals allow a much higher degree of potential curation by experts, thus (presumably) improving information quality, they also require a much higher level of buy-in from the patient, who must choose to exclusively visit the portal for their health information in lieu of more typical forms of Web exploration such as search engines and browsing. Moreover, though a portal may provide access to a curated or filtered set of pages, the pages themselves are generally untouched; we were unable to identify any personal health portal in which the source pages were, themselves, contextually marked-up. We believe that context is an important part of the personalization experience, as is the freedom to explore the Web in any manner the patient chooses. The Personal Health Lens, therefore, was designed to operate over any page, at any time, discovered in any manner, and places its patient-oriented annotations directly into the page-context. This is achieved by utilizing the semantics—both in the patient’s data, as well as in a semantic template query—to generate a contextually-relevant Semantic Web Service-based annotation workflow at the moment the Health Lens is invoked. This workflow may differ depending on the patient’s medical information and the content of the page they are viewing, thus providing the flexibility necessary to operate on the open Web, rather than through a curated portal.

We now describe in detail our prototype system that attempts to identify drugs within the online literature that are potentially dangerous to the user based on their personal health record. We begin by giving an overview of the system and a description of the prototype implementation in the Methods section. In the Results section, we demonstrate use of the prototype in the context of a sample health profile. Finally, we discuss some high-level design issues and provide closing remarks in the Discussion section.

The authors have provided a downloadable demonstration of the Health Lens system as a standalone executable jar file (Multimedia Appendix 8). This jar file bundles all components of the prototype system, including the sample personal health profile, the SHARE query engine, the bookmarklet, and the SADI services for drug interactions and entity recognition. Please note that running the prototype requires a Java Runtime Environment (JRE) to be installed on your system.

To start the system the user must execute the jar file, which can be done on most systems by double-clicking the file. Alternatively, the user may run the jar by typing the following at a Linux/Windows/OSX command line prompt: java -Xmx1g -jar personal-health-lens.jar. Executing the jar file brings up a console that allows the user to start and stop the system on port 8080. (Please note that the current version of the system will only work correctly on port 8080.) Clicking "Start" starts up the local SADI services and the Joseki server that hosts the personal health database.

In most environments, the Start button will open the installation/testing page for the Health Lens bookmarklet in the user's default Web browser. If this does not happen automatically, the user must instead manually visit http://localhost:8080/ in a Web browser. The Health Lens bookmarklet can then be installed by dragging one of the two "Personal Health Lens" links near the top of the page onto the browser's bookmarks toolbar.

The webpage at http://localhost:8080/ can be used to test correct operation of the system. As the content of the test page is under the control of the authors, it provides a reliable means to separate issues with the system components from issues that are specific to the content of particular webpages. To run the bookmarklet against the test page, the user must click the Personal Health Lens bookmarklet in the toolbar, which will activate scanning of the page for dangerous substances. During scanning, an animated SADI logo appears in the top right hand corner of the page. When scanning is complete, the words "St. John's Wort" are colored in red and annotated with a stop sign symbol indicating a dangerous interaction. Clicking on "St. John's Wort" displays a dialog box with the details of the interaction between "St. John's Wort" and the personal health profile, as shown in Figure 2. The warning indicates that St. John's Wort may decrease the efficacy of Alprazolam, a prescribed drug in the user's personal health profile. As evidence, it provides a link to a publication that describes the interaction, which is believed to due to the induction of the CYP3A4 enzyme.

Any webpage may be scanned for personally dangerous drugs by clicking the Health Lens bookmarklet. For example, Figure 3 shows the St. John's Wort warnings in the context of an online article regarding naturopathic treatments for depression [26].

The Personal Health Lens is only one of many tools that have been developed in recent years to leverage personal health data. For example, profile-oriented smartphone applications are now available for identifying allergy-safe foods [27,28], monitoring sleep patterns [29,30], and sharing medical information across physicians and caregivers [31,32]. The use of such personalized tools is likely to continue increasing as new forms of personal health data, such as genotyping and whole genome sequencing, become more readily available to the general public. What makes the Personal Health Lens architecture distinct from other personalization tools is that, in addition to the patient’s data and the set of analytical tools, there is a third component—the semantic model/query—which guides the selection of which tool to use given which set of data. Though in this prototype the semantic model was quite simplistic, taking the form of a SPARQL query relating to drug-drug interactions, the SHARE resolution engine is capable of interpreting significantly more complex models, for example, the clinician’s treatment trajectory for any given patient. As such, we believe this is the first personal health tool which has the potential for clinician-initiated personalized medical advice to be injected into the patient’s own health research browsing activities. Moreover, since the SADI Personal Health Lens has a flexible underlying infrastructure, we believe it can be easily adapted to operate in combination with many of these existing health-information-support tools to enhance the relevance, detail, or quality of their personalization.

The Personal Health Lens project was intended only as a prototype of a novel framework for patient/practitioner/Web interaction, and was not intended to be used by genuine patients. There are some important factors of the personal profile that are not yet taken into account when detecting relevant interactions, such as sex, age, drug dosages, and drug routes (eg, pills, creams, inhalers), to name a few. Beyond these issues, it is useful to point some general concerns with our approach to health browsing personalization, and possible solutions.

Unlike earlier efforts [7], the Health Lens makes no attempt to evaluate the quality of the information on any given page; “hazardous” pages containing overtly incorrect information are not automatically weeded-out, as they are in other portal-based approaches. If there were a public registry of evaluated webpages, this limitation could be partially overcome by adding that registry’s evaluation as part of the annotation pipeline; however, it could not be guaranteed that any page the reader had accessed would exist in that registry. Thus, by ensuring that our systems scales to the Web, we become limited in our ability to filter hazardous or fallacious information. Conversely, the Health Lens system, by not adopting a portal-like structure, becomes a more natural part of the patient’s Web exploration, and one that is under their control. Rather than appearing as a centralized “paternalistic” [5] information source, the Personal Health Lens prototype allows the patient to choose when to bring the expert evaluation framework into their Web experience.

Although Health Lens does not attempt to evaluate the quality of information on webpages, information quality is still a relevant issue with respect to the underlying sources of drug interaction data. In this sense, much of the previous work and lessons learned from designing and maintaining portal-based sites such as MedlinePlus [33] could be usefully applied to Health Lens to build a more transparent and trustworthy system. For example, many metrics (“instruments”) have been developed for systematically evaluating information quality on webpages that might also be used to evaluate the quality of the drug interaction services. Existing information quality metrics are based on factors such as provision of article metadata (eg, authors, date of last update, supporting citations), accuracy of information, completeness of information, and balanced presentation of evidence [34]; there also exist various composite scoring systems, such as DISCERN [35], that employ weighted combinations of these factors. The criteria of completeness is particularly relevant to the drug interaction data sets, as there exists a potential danger that users will assume a substance is safe in the absence of any warnings about interactions. Building a perfectly comprehensive and up-to-date corpus of drug interaction data is obviously not a feasible goal, especially given the distributed nature of the system. This caveat must be made clear to the end users, and they must be reminded to consult a physician before making changes to their medication regimes, regardless of any warnings that the system does or does not report.

Another area where the system can potentially be improved is in catering to the user’s personal level of health literacy. While Health Lens makes no attempt to filter the webpages themselves by literacy level, the user’s literacy is still relevant for the appropriate presentation of warnings. Although we have intentionally described interactions in terms of high-level clinical effects (eg, “decreased efficacy of drug”), the supporting citations provided with the interactions are scientific publications and thus require a high level of medical knowledge to understand. In future work, providing references to trusted secondary sources such as MedLine Plus would probably be more appropriate for most users. As with the issues of information quality described above, our approach to accommodating the user’s literacy level could likely be informed by previous work. For instance, several ontology-based systems have been developed for automatically mapping expert medical terminology to equivalent consumer-friendly terminology (eg, [36,37]), and these might be employed within Health Lens to generate more accessible warning messages. In addition, many sociological studies have employed metrics based on word complexity and sentence length (eg, the Fry Readability Formula) to gauge readability levels of health-related webpages in a systematic manner [34]. These metrics might likewise be employed within the Health Lens framework to help present supporting documents for interaction warnings at an appropriate level of literacy.

Finally, it is important to note that there is a potential privacy concern relating to the use of a public drug interaction service—the system must send the URIs of the user's prescribed drugs out over the Internet in order to retrieve the relevant interactions. In general, there is a trade-off between the degree of privacy the user wants to maintain and the ability to utilize all possible sources of data for identifying conflicts. In future work, this issue can be addressed by allowing the user to indicate which types of data are safe to send over the Web. In addition, the user might also choose to restrict the system to services that support HTTPS. With respect to privacy, the prototype implementation errs on the side of caution by using a locally hosted drug interaction service.

We believe the SADI Personal Health Lens demonstrates that dynamically-generated, context-sensitive pipelines of data and analytical Semantic Web Services can be usefully applied to the personalization of health information on the Web. Moreover, this approach provides the unique ability to fine-tune these workflows through the utilization of expert knowledge within semantically-encoded guidelines. Thus, for the first time, the Personal Health Lens establishes a framework within which clinicians can provide on-demand guidance during their patient’s personal health explorations.