genoDraw: A Web Tool for Developing Pedigree Diagrams Using the Standardized Human Pedigree Nomenclature Integrated with Biomedical Vocabularies

Abstract

The integration of genetic information in current clinical routine has raised a need for tools to exploit family genetic knowledge. On the clinical side, an application for managing and visualizing pedigree diagrams could provide genetics specialists with an integrated environment with potential positive impact on their current practice. This article presents a web tool (genoDraw) that provides clinical practitioners with the ability to create, maintain and visualize patients’ and their families’ information in the form of pedigree diagrams. genoDraw implements a graph-based three-step process for generating diagrams according to a de facto standard in the area and clinical terminologies. It also complies with five characteristics identified as indispensable for the next-generation of pedigree drawing software: comprehensiveness, data-drivenness, automation, interactivity and compatibility with biomedical vocabularies. The platform was implemented and tested, confirming its potential interest to clinical routine.

Introduction

Informatics tools able to exploit genetic information in familial inheritance are increasingly necessary in clinical practice. Making sense of the genetic relations among individuals is an important task even in day-to-day medical activities in the genetics area. However, the availability of applications that allow for registering and visualizing family genetic information is not yet up to par with the necessary requirements for the task. In our long-term collaboration with the 12 de Octubre Hospital, Madrid, Spain, genetics specialists showed an interest in having a tool to facilitate the creation, management and visualization of pedigree diagrams, a visual system to represent families, in the day-to-day clinical activities of these specialists. However, the requirements presented to us for such a tool revealed that some characteristics essential for pedigree drawing systems to be of use in clinical practice are not found in the currently available set of platforms for this purpose. The first characteristic should be (a) that the system complies with the Standardized Human Pedigree Nomenclature – a de facto standard - in its updated version¹ and is able to represent even the less-common scenarios that can be of interest for being documented; (b) that the tool is capable of automating the process of drawing the pedigree; (c) that the system is capable of generating the diagram from structured data. Having the characteristics (b) and (c), the diagrams do not need to be stored as visual diagrams (as images, for instance), but as structured data of each individual represented, as well as relations among them. Thus, data retrieved from medical information systems can be represented as pedigree diagrams with minimal intervention of the user. One of the necessities for this tool was that it was easy to use in a clinical scenario. For this purpose, we concluded that another key characteristic should be (d) that the system would present good usability characteristics, enabling the user to interact easily and rapidly with the interface. Thus, specialists could use the tool to create and manage pedigrees during their medical encounters with patients. Additionally, since the tool must be adapted to work in a clinical environment, some integration aspects should be considered. In our analysis, one integration capability that was especially important was that (e) the individuals represented in our tools should have their traits and diseases annotated as terms extracted from widely-adopted biomedical vocabularies (i.e. Human Phenotype Ontology (HPO)², SNOMED-CT³ and the Online Mendelian Inheritance in Man (OMIM)⁴).

In this paper, we refer to the five described characteristics as (a) comprehensiveness, (b) automation, (c) data-drivenness, (d) interactiveness, and (e) compatibility. They are particularly important in the context of precision medicine, in which very diverse situations must be represented, and data stored in clinical information systems must be retrieved and shown to the specialist. Then, specialists will be able to take more information into consideration when making, for example, a diagnosis, or provide a better, more personalized treatment. Additionally, the presented characteristics offer the possibility to better analyze the way in which families are structured and how genetic diseases are inherited, opening possibilities in statistical and medical research.

An analysis of the pedigree diagram drawing tools and platforms currently available revealed that some of the five characteristics can be found in some of these platforms. Examples of such platforms are Madeline 2.0⁵, My Family Health Portrait⁶, CRA Health⁷, Progeny⁸, and GenoPro⁹. However, none of the tools analyzed combine the five characteristics simultaneously. Furthermore, none of the tools implement the updated version of the nomenclature mentioned above¹, and, to our knowledge, none of the systems support the annotation of diseases as terms from biomedical vocabularies. In order to offer a solution that aims to comply with the five characteristics identified, we developed genoDraw (www.genodraw.com). In this work, we present the foundations on which this system is built.

Methods

We identified the five characteristics that we believe are necessary for a better acceptance of this kind of system in clinical practice. Hence, the foundational idea around genoDraw is to be a platform for the creation, management and visualization of pedigree diagrams. In this section, we present the basis of our approach for the representation engine and the strategies that we applied so that each of the characteristics (a-e) is addressed by genoDraw. In our specific case, a web-based platform was ideal. At the end of this section, we present the architectural aspects of our system and other implementation details.

First, to represent the pedigree diagrams, we follow the Standardized Human Pedigree Nomenclature^{1, 10}. This nomenclature is a recommendation of the National Society of Genetic Counselors and it is a current de facto standard in the discipline. The definitions and rules established by the updated version of this nomenclature¹ enable us to define an algorithmic process for the diagram creation in a broad range of reproductive scenarios. Examples include planned adoptions, ovum donations, surrogate gestations, as well as the expected usual situations, such as single and multiple gestations.

Second, to correctly store the necessary entities and links and draw them on a canvas, we represent the diagram internally as a graph (structured data). Entities (nodes) of this internal graph are individuals, gestations and relationships. In each of them, data are stored. For instance, a gestation can be monozygotic or not when more than one child is listed, and an individual might be affected by a certain trait. A second graph, the one to be drawn as a pedigree diagram, is generated using data describing these entities and their relations (biological parenthood, partner of a relationship, etc.). This is accomplished using the three-step process described below.

The three-step process involved in drawing pedigree diagrams is responsible for transforming the internal graph, which stores what is essential to the representation as structured data, into the representation graph. The representation graph, in turn, follows the nomenclature and does not necessarily contain the same nodes and links as the internal one. In fact, in many scenarios, the representation graph will be composed of more nodes and fewer edges than the internal one. For example, the internal graph stores, for each gestation, each of the parents. However, when a relationship between the parents is identified, only one link between the relationship and the gestation is drawn, and not those between the gestation and each parent. As an illustration of this example, Figure 1 shows, on the left-hand side, the objects of the internal graph relative to three individuals (A, B and C), a relationship (R) and the gestation of C (G), as well as the connections among them. The resulting nodes and links of the matching pedigree diagram, drawn after following the three steps, are shown on the figure’s right-hand side.

Figure 1:

A simple example of generation of a pedigree diagram from an internal graph. The internal graph is represented visually on the left side of the image, and the representation graph on the right side. As we can see, the links between the gestation and each parent are substituted by one link between the gestation and the relationship of the parents. This simplification is only done when possible. In accordance with the adopted nomenclature, an empty circle corresponds to a female individual and an empty square to a male. The horizontal line between A and B is their relationship, and the vertical line symbolizes that both are parents of C. The gray circles over the relationship and gestation nodes are added for usability purposes.

The first step of the three-step process generates each of the nodes to be drawn. This step decides which entities are to be drawn or not and draws the squares, circles, diamonds and other artifacts that visually represent each entity. For individuals, characteristics such as gender, being deceased or not, and traits by which they are affected are characteristics that are reflected in the symbol drawn on the canvas. In Figure 1, for instance, the individual C is affected by sickle cell anemia (OMIM: #603903). This disease is annotated as a term from the Online Mendelian Inheritance in Man (OMIM)⁴ and, as described later, is included in a collection of traits of the corresponding individual as a reference to such term in the OMIM vocabulary. This characteristic is reflected in the representation graph as a gray mark in the node that corresponds to the individual C. In the case of gestations, only those that correspond to multiple gestations will have drawn at the node other than the gray circle, which we add for usability purposes as discussed later. When a node refers to a relationship, only cases of infertility and divorce are annotated visually. Otherwise, only the gray circle is drawn.

The second step generates the edges between represented nodes. Visually, they are the straight lines that connect related entities in the pedigree diagram. This step is based on rules derived from the nomenclature, and explores the internal graph, searching for specific patterns that correspond to drawing a connection between two nodes of the representation graph. Thus, this is the step that makes sense of the relations between nodes. A person is to be connected with his or her gestation if such gestation is decided to be drawn by the previous step. Similarly, a gestation is connected with each parent, or their relationship, if there is one. A relationship, in turn, is to be connected with both partners. By applying the previously mentioned rules, from a given situation we are able to reach a representation graph that is isomorphic to the pedigree derived directly from following the directives of the nomenclature we adopted, with some extensions that will be discussed later.

The third and last step for displaying a pedigree diagram as a graph is the definition of rules for the positioning of the nodes. In our system, the positions of the nodes are calculated following an optimization process conducted after the three steps. One of the inputs of this optimization process is information about which rules need to be vertically or horizontally aligned. Similarly to a solution proposed elsewhere¹¹, we define linear constraints for each of these alignments. The third step is the step which generates such linear constraints. This is done by exploring the internal graph in a similar manner as in the second step (by searching for specific patterns that activate rules for the relative positioning of the nodes). An activation triggers the creation of constraints that are followed by the optimization process. One example of alignment rule is that a node of type gestation is to be vertically aligned to the child if there is only one child. As it is depicted in the right side of Figure 1, the node corresponding to the gestation of the individual C is vertically aligned to the node corresponding to the individual C.

After the third step, we obtain a representation of the pedigree diagram. The nodes are drawn on a canvas visible to the user, the connections (edges) between the nodes are also defined and drawn, and the constraints for alignments are defined. From this point on, the representation is handled by an engine specialized at arranging the nodes on the canvas according to an optimization algorithm and displaying this representation to the user. The optimization algorithm outputs positions for each of the nodes complying with the constraints defined. The optimization is, therefore, the minimization of a stress function with constraints. The function measures the difference between an ideal distance and the current distance between two nodes directly connected. This ideal distance is calculated for each edge of the graph and depends on the types of the nodes it connects. The minimization process is done iteratively and is repeated whenever a change to the representation graph is done. For example, when the user moves a node to another position, the minimization is triggered, changing iteratively the positions of the nodes until a new convergence is found. For the specific purpose of this module, we implement a solution based on an already-existing library¹² that provides an optimization algorithm that is useful for our necessities and enables the user to interact with the representation graph by moving the nodes.

As an illustration of the whole three-step process, we include Figure 2, in which the individual B is affected by, for example, sickle cell anemia (OMIM code: #603903), has a relationship with A and has had one with C. With individual C, B had twins. We do not know if the gestation was monozygotic, hence the question mark (?) below the gestation node. Both daughters are affected by the disease. The individual B now has a relationship with A, and they adopted F. The dashed line is drawn as so because, since the child is adopted, there is a nonbiological relationship between each parent and the adopted child.

Figure 2:

Example of the three-step generation and arrangement processes. On the top-left are nine generated nodes that are the output of the first step of our process, which defines which nodes are to be drawn and draws them according to the nomenclature, with a few stylistic changes. Next, the second step defines the connections between nodes, which are the gray lines drawn. After that, the third step defines the constraints that the optimization engine uses to arrange the nodes on the canvas.

In terms of the characteristics we aimed for our system to possess, by having followed the updated Standardized Human Pedigree Nomenclature¹, we can ensure that our system can be, in principle, comprehensive enough to represent all the major scenarios that exist in our society. However, we detected some limitations that violated this ideal. One of the limitations is that, according to the symbology of the nomenclature, it is not explicit how a gestation with multiple children should be represented in the case of gestational surrogacy. Another limitation is that, if two individuals that have a relationship have family members in common, they might be included in different generations, thus, horizontally aligning their relationship edges is not feasible. In our system, we addressed these limitations by extending the nomenclature, making it more flexible when this would not render the pedigree diagram nomenclature ambiguous. Our minor changes provide more consistency and flexibility to the representation. In the case of the representation of multiple gestations, we chose to always show the gestation of a person when the parents of this person are also represented. That way, if it is the case of a multiple gestation, two people will be connected to the gestation. In the case of multiple gestation in the context of gestational surrogacy, for example, with our extension, there is no restriction to the child being only one. For the second limitation, in which the two partners of a relationship are members of different generations of the same family, our solution is the removal of the constraint of the partners being horizontally aligned only when there is a conflict in their generations. By implementing a system with our extended nomenclature, we ensure a wide comprehensiveness, by which the system is capable of representing all the situations that can be modeled following the directives of the nomenclature, which are most of the common situations that one can observe in the population.

Data-drivenness and automation are both addressed by defining our three-step process with the focus on generating the diagram from structured data of individuals and their relations and by implementing a representation engine based on optimization¹³. Up to the end of the third step of our three-step process, the generation is fully automated. Having the nodes, the edges and the constraints (alignment rules) that define the pedigree, the representation engine arranges the nodes following an iterative optimization process. The full automation of the representation engine is not possible mainly for two reasons. The first is that structures reached by the optimization engine can be the result of convergences to local optima. That is, the ideal positioning of the nodes might not be reached. The second reason is that personal inclinations of the user are not considered during the positioning of the entities in the canvas. Both reasons might cause a need for small corrections and adjustments to the arrangement of the pedigree.

By allowing the user to move the nodes of the pedigree while keeping the constraints active, we address part of the fourth characteristic we defined as important for our system, which is interactiveness. If the disposition of the nodes does not satisfy the user, he or she can change the positions of some nodes and a new iterative process is initiated, and convergence around the new arrangement is reached. One important characteristic of our representation interaction model is that, while a node is being moved, no rules of the disposition of pedigree diagrams are disregarded. That way, while allowing the user to make changes to the drawn diagram, our system ensures that the representation is correct. Another feature that also contributes to interactiveness is the possibility to add and remove entities of the internal graph by interacting with nodes and context menus associated with each node of the pedigree. From the changes caused in the internal graph, another representation is generated and displayed. When possible, the positions of the existing nodes are kept, so that the user does not need to make any further changes to the parts of the diagram that were already arranged to their expectations. To edit information regarding a specific entity of the internal graph, we implemented a sidebar menu through which information about individuals, gestations and relationships can be inserted, changed or removed. Additionally, to provide better usability of the representation system, we represent the nodes that would correspond only to changes of directions between lines in a paper-based diagram with a semi-transparent gray circle. This feature enables the user to better understand with which entities of the canvas he or she can interact, either by dragging to define a new position or by clicking to view or edit the data associated with the entity that corresponds to the node clicked.

From a usability perspective, the user interacts with the canvas both directly and indirectly. Direct intervention is preferred for simple actions, such as the creation or elimination of entities. Adding a child to an individual, eliminating one or hiding it from the canvas are also direct interactions triggered using context menus directly on the corresponding nodes in the canvas. Indirect interaction is preferred for more complex actions, such as changing the name of an individual or adding another child to an existing gestation, which are made using a sidebar menu. Depicted in Figure 3 is the interface that allows managing a diagram. As we can see, the context menu in the center can trigger simple actions, while the sidebar menu on the right is used for more complex data changes.

Figure 3:

Interface of genoDraw. The user is editing the example used in Figure 2 to add a partner to the individual F. As we can see in the sidebar menu, the relation between F and A and F and B are of type ”nonbiological parenthood”. Other information available for the individual F (i.e. gender, name, fertility, etc.) is shown in the different sections of the sidebar menu, which can be extended and collapsed.

The last characteristic we defined as being fundamental for a pedigree drawing software to include in the current context of data integration is compatibility with widely adopted biomedical vocabularies for the annotation of genetic traits and diseases. In this regard, we enable the user to assign traits to individuals in such a way that the traits are considered by the system as terms from biomedical vocabularies. Examples of vocabularies supported by genoDraw are HPO², OMIM⁴ and SNOMED-CT³. Depending on license-related aspects, the selection of vocabularies can be changed. In this regard, genoDraw can operate on an unlimited number of vocabularies. This compatibility with biomedical vocabularies provides various advantages, such as common reference for each disease, and the possibility to develop further methods to make statistical analysis of the data inserted in internal graphs.

In terms of the architecture of the system, because genoDraw is intended as a platform for the creation, management and visualization of pedigree diagrams, a web-based system was ideal. In Figure 4, we describe the architecture of genoDraw. After creating a pedigree by interacting with our platform and inserting information of individuals and their relations, the user can save locally a file that includes the internal graph. Having this file, the user can load it on the platform to visualize the pedigree and make further changes to it.

Figure 4:

The architecture of genoDraw. The user interacts with a web client application connected with a backend that only handles the distribution of the website itself and the authentication of users. The internal graphs (structured data) are files which are stored locally in the user’s device.

As illustrated in Figure 4, genoDraw contains a backend that authenticates the user and provides the necessary files for genoDraw to work in the web browser of the user. The internal graph files are, in our implementation, JSON (JavaScript Object Notation) files managed by the user. An internal graph file contains the necessary information to generate a pedigree diagram (i.e. individuals, relationships, etc.). Such a file can be loaded into the platform but is never uploaded to the server. After making the desired changes or visualizing the pedigree, the user can choose to save the internal graph as a file, which is the same file that can be loaded again into the platform in the future for further changes or visualization. One detail of our implementation is that we make use of a database system to handle authentication information. A web server (backend) handles this authentication process and serves the files corresponding to genoDraw to the client. We implemented genoDraw in JavaScript, making use of D3.js¹⁴ and WebCola¹² as libraries for handling the visualization. We selected WebCola as the graph-handling library due to its capability to keep the alignment constraints active while the user manipulates the graph, as well as its capability to handle the structuring process of the diagram (optimization process) based only on alignment rules (constraints). Furthermore, it allows for an interactive use in a wide range of devices, of which traditional computer devices, such as desktops and laptops, as well as tablets, are the most used by our target users.

Results

We designed genoDraw to be adopted in clinical practice as a platform of intense, day-to-day use. Genetics specialists are expected to use our tool in medical encounters.

To evaluate the usability of our system, we have carried out a usability test. The objective of the test was to analyze the time required for a subject to be acquainted with the platform and to observe usability variables, such as if the user was capable of finding the way to insert or alter specific data in the diagram, and how long it took. Additionally, we obtained feedback from the users with some satisfaction questions. The subjects were 26 graduate students in the area of biomedical engineering who had been previously informed about the nomenclature but had no knowledge of our tool. We first let them explore the platform for a few minutes. Then, we presented the students two scenarios of different complexities in plain text and asked them to represent the scenarios as pedigree diagrams using genoDraw. The scenarios contained multiple gestations, ovum donations, surrogate gestations and adoptions, so as to observe what kinds of usability problems could exist in the insertion of the more complex and uncommon scenarios. Furthermore, we asked the students to insert traits and diseases of each individual as specific terms from standard vocabularies. The results of the usability test revealed that most users were familiarized with genoDraw in less than 30 minutes. We also observed that the time required for the users to represent both scenarios ranged from 20 minutes to 50 minutes. The average completion time was 20 minutes for the first scenario and 10 minutes for the second. In the first scenario, which contained a family with a case of multiple gestation, some of the users had difficulties finding the correct way of inserting such type of gestation. We interpret this as a usability issue, since the only path to add a multiple gestation at that moment was to include an additional child to an existing single gestation. In the second scenario, an ovum donation was to be represented, which meant that the users should insert the donor as biological mother in the gestation of the child. While most of the users found the path to adding such information in the pedigree without much effort, many agreed that it was not an intuitive solution. Having detected these and other usability issues, we addressed them.

To assess the correctness of the pedigree diagrams generated using our system, an evaluation of the tool was required to detect and address any incompatibilities or deviations from the standard nomenclature adopted for our system. In our case, we conducted this assessment by progressing through some case studies step-by-step. These practical scenarios were designed by experts at the Genetics Unit of the 12 de Octubre Hospital to serve as examples for our evaluation in plain text. After methodically introducing each of the examples in genoDraw, we then compared our results with the recommended results also given by the experts. During this evaluation phase, we detected some issues regarding the correctness of the tool and solved them.

An example of one of the validation cases is the following: A couple is formed by a man (A) and a woman (B). The woman is affected by retinoschisis in its X-linked recessive variant (OMIM code #312700) and has had, with the same man (A) with whom she forms a couple, one son (C) also affected by the disease, and is pregnant with a child (D). She has a brother (E) who is also affected and a sister (F) who is not. Her father (G) is also affected by the same disease and is married to his cousin (H), who is the mother of B, E and F. Our result for this example is shown in Figure 5. Having a representation generated from a case such as the example described, a specialist is able to visualize the family, assessing the risk of the child in pregnancy being affected by the disease, as well as identifying other family members who might be, for example, carriers of the disease.

Figure 5:

Pedigree represented by genoDraw for one of the examples used during the validation of the tool.

Discussion

The purpose behind genoDraw is to provide genetics specialists with a tool to address their needs. In this work, we identified these needs as five characteristics the tool must possess, and designed a tool that provides the resources necessary to create, manage and visualize pedigrees via its ability to provide solutions for each of the five characteristics.

genoDraw is a tool intended to be used in clinical practice by medical specialists in the area of genetics. For this reason, we carried out a thorough evaluation of our tool, focusing not only on its correctness, but also on its ease of use. With genoDraw’s current capabilities, a specialist can insert information during a medical encounter and observe specific characteristics of the family of the patient. This is undoubtedly an advantage of any pedigree representation, even when sketched on paper. However, since the pedigree diagrams in genoDraw are generated automatically from the data inserted, the user does not need to plan which entities should be drawn. That way, the composition of a pedigree diagram is as easy as a step-by-step insertion of information. Additionally, since the arrangement of the diagram is done automatically, no planning of where each entity should be drawn is needed. Thus, according to our observations, genoDraw is capable of enabling an improvement in clinical practice.

In terms of the limitations of our tool, some should be noted. The first is that, despite the fact that the representation engine is flexible, it is constrained by the bidimensionality of the canvas on which the diagram is drawn. Thus, issues such as the planarity of the graph being represented or the alignment impossibilities, described elsewhere¹¹, are unavoidable. Another limitation is the algorithmic procedure used to arrange the nodes of the graph in the canvas. Although the generated graph is always correct according to the nomenclature with our additional described changes, the structure is defined by a process that does not consider factors such as the personal appreciation of the user, who might want a specific arrangement of the nodes. In this case, we present a solution by enabling the user to make changes to such positions so that the optimization process finds a new convergence around the new structure. Further enhancements improving the tool’s ability to adapt to the user’s preferences should enable the generation of better-arranged pedigree diagrams.

Additionally, the presented platform is currently capable of storing the individuals’ diseases and traits as terms from widely used biomedical vocabularies. Although this is a novel feature, it does not yet enable full integration of the system with other, currently used, systems. We intend now to expand the compatibility of our system towards the integration with the represented individuals’ electronic medical records. This could make of our system a tool that retrieves, updates and uses other relevant information stored in these records to enhance and facilitate the risk assessment and diagnosis of genetic diseases. A future development in this direction will be the expansion of the system with the capability of generating clinical messages that can be stored in clinical environments, thus integrating the tool with other currently used clinical data storage systems.

When compared to other tools that serve the same purpose, we believe genoDraw is uniquely suited. In terms of comprehensiveness, our tool is the only system reported in the literature that complies with all the directives established in the updated version of the Standardized Human Pedigree Nomenclature¹. In this regard, the flexibility of our model is key to this characteristic. Another solution¹¹, for example, considers that every individual is child of a relationship, not being flexible enough to register that one’s biological parents might not have any relationship, such as in the case of sperm donations. As far as interactivity is concerned, our solution for arranging and moving the entities of the pedigree on the canvas enables the user to interact with the diagram without rendering it incorrect. According to our observations, this is superior to other solutions proposed. In GenoPro⁹ and in the online version of Progeny⁸, for example, the structure of the pedigree can be voided by moving nodes. In terms of compatibility with biomedical vocabularies, to our knowledge, genoDraw is the only tool that enables the annotation of diseases as terms from biomedical vocabularies. Lastly, the automation and data-drivenness provided by genoDraw are enough to generate a plausible pedigree diagram for all situations, while other tools that generate pedigree diagrams from data tend to present various limitations in this regard.

Conclusion

In this work, we present genoDraw, a platform for representing, creating and managing pedigree diagrams, which is built around five characteristics that we identified as necessary for the next generation of such tools. The central module of this platform is a representation engine, which is capable of deriving a pedigree diagram from structured data. In order to integrate the system with other medical resources, our implementation is also compatible with annotations of diseases and other traits as terms from widely adopted biomedical vocabularies, in our case SNOMED-CT, OMIM and HPO. Depending on licensing aspects, the selection of available vocabularies can be changed, and many vocabularies are compatible with genoDraw. Our system supports the visualization and creation of pedigree diagrams from and to structured information that can come to be stored in medical information management systems, and the diagrams are generated following the Standardized Human Pedigree Nomenclature in its updated version. Thus, genoDraw is a tool that can improve the current practice of sketching pedigrees on paper by providing genetics specialists with useful computing capabilities that include the ability to conveniently input information during a medical encounter, the fact that this input data is kept as structured data that can be used to update the information of patients, as well as the ability to share internal graph files with other health professionals in order to provide a better, more precise treatment.

In the near future, we intend to integrate genoDraw into the day-to-day workflow of specialists in genetics and other areas for the assessment of the genetic component of various illnesses in patients. In terms of its use in research, we envision genoDraw as being a tool with the potential to support data collection of individuals and their families.

Acknowledgment

This work is supported by “Proyecto colaborativo de integración de datos genómicos (CICLOGEN)” PI17/01561 funded by the Carlos III Health Institute from the Spanish National plan for Scientific and Technical Research and Innovation 2017-2020 and the European Regional Development Funds (FEDER).