1 Introduction

The utility of Family Health Histories (FHHs) has been widely recognized, and is increasing as more and more diseases are linked to genetic factors [1, 2]. FHHs, also known as Clinical Family Histories, help practitioners in the diagnosis and risk assessment of patients and their family members in a cost-effective manner; provide insight as to the most adequate course of treatment for patients [2–4]; and enable the identification of at-risk individuals before diseases manifest, opening the possibility for counselling and preventive measures to delay, diminish or completely avoid diseases or symptoms [5].

There are several formats available to represent FHHs, both in text and graphical form [6–8]. The clinical pedigree, henceforward referred to as pedigree, is a broadly used graphical representation that combines genealogical and clinical information and offers a good balance of simplicity, expressivity and detail [4]. It is subject to standardization by the Pedigree Standardization Work Group (PSWG) that regularly issues recommendations regarding the use of symbols, annotations and layout of pedigrees [9, 10]. Figure 1 presents an example pedigree in PSWG notation, regarding a family with a history of sickle cell disease.

Fig. 1.
figure 1

Example pedigree in PSWG notation

Full size image

Several software packages allow the creation of such pedigrees [11–24], yet few integrate with existing Health Information Systems (HIS) or Electronic Health Records (EHR). Using different, disconnected tools for recording patient data and FHHs not only makes information less readily available, but also potentially results in out-of-date information and incoherent data. This problem is addressed by OntoFam [25], an ontology-based clinical pedigree information system that can be integrated with existing HIS.

During the conception of OntoFam, the team was confronted with the decision of whether to build or reuse a pedigree drawing engine (PDE) for the system’s user interface. An investigation revealed that several open-source PDEs were available for reuse, though none inherently offered the desired degree of interactivity. In fact, most existing engines follow a “static” approach: they accept an input in a structured text format and output a graphic pedigree representation; any editing involves constructing a new input to obtain an updated pedigree. However, by wrapping an existing static PDE with additional functionality, it is possible to create an interactive visualization. This was the approach chosen for OntoFam.

This paper presents OntoFam’s interactive pedigree visualization, which allows the dynamic creation and management of pedigrees. It reuses an existing static pedigree drawing engine and extends it to allow end users to directly manipulate patient information and family structure. Section 2 presents the method used to construct the visualization and Sect. 3 describes the evaluation strategies and presents the corresponding results. Section 4 concludes this paper.

2 Method

Madeline 2.0 Pedigree Drawing Engine [18] is the chosen PDE for the basis of OntoFam’s pedigree visualization tool due to a unique combination of favorable characteristics:

  • It generates pedigrees that conforms to most PSWG recommendations;

  • It is able to correctly represent complex family structures that some other engines do not handle [26];

  • It generates pedigrees in Scalable Vector Graphics (SVG), an XML (eXtensible Markup Language) based format that is rendered as vector graphics in modern browsers and is editable in external software, such as Inkscape, CorelDRAW or Adobe Illustrator;

  • It is an open-source project, allowing aspects of the representation to be extended or fine-tuned, should the need arise;

  • It is actively maintained (the most recent version is from mid-August, 2014).

In its current form, Madeline is a “non-interactive program that is executed from a shell environment” [27], that is, it is invoked through the command-line and accepts parameters to customize the output. Input data must be formatted in one of the several table-based formats allowed. Upon invocation, Madeline renders the corresponding pedigree onto a file in SVG format. Any changes to the rendered pedigree involve either editing the SVG in a compatible image editor or altering the input data and repeat the pedigree generation process.

A separate project that shares some of Madeline’s authors, dubbed Madeline 2.0 Web Service, does allow pedigrees to be built interactively [28]. However, at present this service is closed-sourced, does not fully exploit Madeline’s capabilities and requires direct manipulation of the inherent input data-table for relatively trivial tasks (such as identifying the proband, setting deceased states of specifying clinical conditions, among others).

OntoFam uses a different approach, in which the data-table input is completely hidden from the end user. The intent is to provide a user interface that is closer to practitioners’ mindset, allowing data to be manipulated in a way that conforms to their needs and view-points, rather than those of the pedigree drawing engine.

The fact that Madeline uses SVGs was particularly relevant in the construction of OntoFam’s visualization method. SVG is an XML language that uses elements to represent lines and shapes that, once rendered on a web browser, allows client-side script to interact with the elements and corresponding shapes. This enables end users to interact with pedigree elements and provides immediate solutions to the needs of selecting or activating represented individuals – client scripts react to the user action of clicking an individual by changing its visual aspect (i.e., changing the CSS style of the corresponding SVG element) and display a pop-up window with detailed patient information when an individual is double-clicked.

To add new individuals to the pedigree, menu options are provided to allow the insertion of relatives to a selected individual. For example, upon selecting an individual whose ancestry is not yet filled in, the interface will provide options to add the corresponding mother and father. Spouses, siblings and offspring can be added to individuals at any time. This “chained” insertion of individuals ensures that the family structure is always valid. Figure 2 presents OntoFam’s user interface while editing a pedigree with 4 generations, and Fig. 3 exemplifies an individual’s popup form, allowing its information to be viewed and edited.

Fig. 2.
figure 2

OntoFam’s user interface editing a 4-generation family pedigree

Full size image
Fig. 3.
figure 3

Example popup form displaying the properties of an individual

Full size image

OntoFam consists of a web application that uses single-page application (SPA) techniques to wrap Madeline’s invocations and provide an interactive experience. Whenever the user requests the pedigree information to be changed, the following process occurs:

  1. 1.

    The user requests the addition, edition or deletion of an individual;

  2. 2.

    Client-side script validates the user action and sends the corresponding information to the web server;

  3. 3.

    OntoFam’s family database is updated with the new information;

  4. 4.

    The current FHH is formatted according to Madeline’s requirements;

  5. 5.

    Madeline is invoked and an SVG pedigree is generated;

  6. 6.

    The SVG is post-processed on the server;

  7. 7.

    The post-processed SVG is returned to the client and rendered on the browser, replacing the previous pedigree representation.

Step 6 is used to fine-tune visual aspects and overcome Madeline’s limitations, such as the lack of individual and generation sequential numbering. The same effect could have been achieved by extending Madeline’s source code, but the team found preferable to use Madeline as-is and treat it as a “black-box”. This illustrates a useful characteristic of SVGs: because they are XML documents, it is fairly easy to process and manipulate an existing graphic, unlike raster-based image formats.

Wrapping Madeline in this manner also allows OntoFam to replace its PDE with relative ease, should the need arise. Assuming the replacement engine produces comparable SVGs, the system changes will be limited to the translation of FHH information into the format accepted by the new engine.

Even though the process involves a number of steps, response times are adequate and users are not aware of delays caused by server roundtrips. The XMLHttpRequest (XHR) Application Programming Interface (API) is used in the background to exchange data with the server and, on step 7, user selections are preserved and scroll positions are maintained to ensure that, from the end user’s point of view, the pedigree representation was “instantly” complemented with the new information.

3 Evaluation and Results

OntoFam is currently being integrated with an existing HIS for Hemophilia care – Hemo@Care [29]. Hemophilia is an X-linked congenital bleeding disorder, with an estimated frequency of 1 in 10,000 births [30]. Because Hemo@Care deals with a hereditary condition and is also developed in the University of Aveiro, it is an excellent candidate for integration with OntoFam. However, the fact that Hemophilia is a rare disease poses some challenges when it comes to evaluating the resulting system, namely the limited number of practitioners knowledgeable in Hemophilia care. Thus, it proved necessary to use evaluation strategies that could be applied with a limited number of participants. The chosen approach involves three distinct evaluation techniques, executed at different development stages:

  • Use of an iterative development process, resorting to expert reviews to validate the most significant iterations and guide the forthcoming development;

  • Conduction of user experience tests with (necessarily few) real users (practitioners knowledgeable in Hemophilia care) at project milestones, to assess overall system acceptance in real-world scenarios;

  • Conduction of usability tests with non-expert users in greater numbers (students of Human-Computer Interaction [HCI] courses), to fine-tune the user interface and possibly detect generic (non-domain) usability problems.

Details and results of each technique are described in the following subsections.

3.1 Expert Reviews

A number of reasons determined the use of expert reviews to guide the development of the visualization. As previously mentioned, the number of available practitioners is very limited, due to the disease’s rarity. Also, at early exploratory stages of development the user tasks are not always completely understood, hence controlled experiments with concrete tasks do not yet apply [31]. Finally, the team was interested in understanding what high-level cognitive tasks, such as decision-making and insight generation, are involved when using a pedigree management system in the context of Hemophilia care.

Two experts were involved in the periodic reviews: an HCI expert and a medical doctor with ample experience in Hemophilia care. The HCI expert relied on heuristic evaluation and personal experience to detect problems and validate design choices, while the medical doctor acted as a test user and, most importantly, enlightened the team regarding what low and high-level tasks were deemed necessary in her field. For example, it was revealed that women in reproductive age within a family with a history of Hemophilia should be educated about the possible implications in offspring, thus gender and age should be clearly represented in the visualization. The presence of inhibitors is also of great importance; therefore it should be visible on the pedigree. It was also learned that due to the X-linked nature of the disease, a pedigree can be used as a “map” to differentiate individuals that should be studied from those that can do without study (and thereby spare human and financial resources).

3.2 User Experience Tests

When expert reviews determined that the system was useable and feature-complete, the team proceeded to conduct user experience tests. The objectives of such tests include obtaining “subjective feedback and opinions on the visualization tool” [32] and assess the system adequacy in real-world scenarios. This is not a “final test”, but rather an iterative process, where the results of a test session influence the next iterations of the development process and the design of the following test session.

Thus far, the team has conducted the first round of these tests. Two medical doctors knowledgeable in Hemophilia care were invited to participate, guided by three observers. After an open exploratory conversation, where the utility of pedigrees within the Hemophilia field was discussed, they were given a 10 min presentation on the system goals and functionality. They were then allowed to freely explore the system for another 10 min, where they created fictional test pedigrees. The team had prepared a set of introductory tasks to ensure familiarity with the system functionality; however, the participants found their way around the user interface with great ease and the observers were unanimous in deeming these tasks unnecessary.

The participants proceeded to the second set of tasks, which involved constructing a 4-generation pedigree with 26 individuals, similar to that represented on Fig. 2; analyzing existing pedigrees to detect individuals that should be studied and individuals that were unnecessarily studied; and analyzing an incorrect pedigree to detect errors, taking into account the known hereditary patterns of Hemophilia. Upon completing each task, participants were asked to rate its difficulty using a Likert-like scale. After performing all tasks, the participants were asked to answer a questionnaire to evaluate system quality and adequacy.

All tasks were correctly performed by both participants, with the exception of the pedigree construction. On this task, one of the participants confused the 4th generation branches and constructed an incorrect family structure. Nearing the end of the task the participant realized this problem but was told not to correct it, seeing as it was the system that was being evaluated, and not the user. This error suggests that functionality to indicate an individual’s relation to the proband may be a useful addition to the user interface. Both users rated all tasks as easy or very easy, and all tasks were completed within the estimated completion time.

The answers to the questionnaire were very positive, with both participants agreeing that the system is adequate to represent FHHs related to Hemophilia care, and that they would both use the system and recommend it to colleagues (one participant mentioned that she would also like to use the system applied to the Thrombophilia field). When asked to rate the overall system on a scale of 1-10 (greater is better), one participant awarded an 8 and the other awarded a 9-10. No major problems with the system were found by the participants, though both provided suggestions for further development: the inclusion of molecular study information (on the patient data but not necessarily on the pedigree) and the possibility to represent adoptions (not completely necessary when dealing with hereditary diseases, but relevant nonetheless to get an holistic view of families with adopted members).

A second round of user experience tests is scheduled to occur shortly following the time of this writing, with participants distinct from those of the first round.

3.3 Usability Tests

Usability tests with a much larger number of participants are planned for the 1st semester of 2015. These will consist of controlled experiments performed by students of Human-Computer Interaction (HCI) courses in the University of Aveiro. Although these users are not domain experts, their familiarity with user interfaces and usability guidelines is likely to allow the detection of generic usability problems. User performance metrics, such as task completion time, error ratio and number of clicks, among others, may also help improve interface design.

4 Conclusions and Future Work

The method used to create OntoFam’s interactive pedigree visualization by wrapping an existing pedigree drawing engine has proved successful. It hides the process of constantly feeding the PDE with new input to generate new output, and instead presents users with an environment where pedigrees can be directly manipulated. Even though the process involves server roundtrips and constant pedigree regenerations, the fact that these occur in the background and that the visual context is maintained (such as selection and scroll position) keeps users unaware of the actual complexity. In their view, the pedigree is instantly updated on the client browser whenever changes are made.

The results obtained in the concluded evaluation stages have been favorable, with comments and suggestions mostly pertaining to additional functionality rather than faulting the existing system. Results also suggest that practitioners already familiar with clinical pedigrees will have little or no trouble adapting to the visualization. Even though these are promising results, it must be noted that, thus far, the number of participants has been very limited and that broader evaluations should be performed. This will be the focus of forthcoming evaluation stages.