GENOMIC NETWORK SERVICE USER INTERFACE

A genomic update system can generate a user interface from network pages based on user variant data and network services associated with the network pages. A trait data structure tracks network services for different trait categories. A given network page of a given category can be used to identify a different category and different network services and content for display to a user. Content in the trait data structure can be included in a user interface with additional contextual visualizations that allow the user to interact with the links and content via a user device, such as a handheld mobile device.

FIELD

The present disclosure generally relates to special-purpose machines and improvements to such special-purpose machines, and to the technologies by which such special-purpose machines become improved compared to other machines for generating a genomic user interface comprising user data.

BACKGROUND

Users now have the ability to access genomic tests and services that were recently available only through leading research organizations and clinical laboratories. The decreasing cost of genome sequencing has been one factor in increasing the availability of such direct-to-consumer genomic services. Such genomic services can now quickly complete laboratory analysis of a user's genetic data (e.g., deoxyribonucleic acid (DNA)), and give the user access to the genetic data. These breakthrough advances have created several technological challenges due to the size, complexity, and nature of genetic data. For instance, while a given user can now have their genome sequenced, the resulting sequence data can often exceed hundreds of gigabytes of text data, which can be difficult to store and analyze even in a compressed format, let alone via mobile client device. Additionally, the sequenced data is very complex and understood by few users. Furthermore, access to the genetic data should be controlled in a secure way to ensure privacy of the user's genetic data.

DETAILED DESCRIPTION

The description that follows discusses systems, methods, techniques, instruction sequences, and computing machine program products that illustrate examples of the present subject matter. For the purposes of explanation, numerous specific details are set forth in order to provide an understanding of various embodiments of the present subject matter. It will be evident, however, to those skilled in the art, that example embodiments of the present subject matter may be practiced without these specific details.

As discussed, users can now access their genetic sequence data via direct-to-consumer genomic services. While users have access to their own sequence data, the sequence data can still be difficult to manage due to its large size and unique structure (e.g., a variant data format that describes variations between the user's sequence data and reference sequence data). Further, the field of genetics is rapidly changing as new discoveries are made and new studies are published. It can be difficult for trained professionals (e.g., scientists) and regular users (e.g., non-scientists) to keep current with genetic news and determine whether the news is relevant to their genetic profile.

To this end, a genomic update system can be configured to identify genetic content items (e.g., journals, studies, blogs, news webpages), and correlate them to user data (e.g., genetic sequence data, user variant data) using a trait database. The genomic update system can compare a user data to genetics data in the genetic content items, and transmit a notification (e.g., an email, a mobile application user interface) to the user that indicates that new genetic content is available. The notification may include visualizations that compare the user data to the newly available genetic content. The notification can further include one or more links to network services of applications that the user can access to further analyze the user data. Which network services are included in the notification can depend on how the genetic news item is categorized in the trait database.

In some example embodiments, the content included in the user interface can depend on how the user's genetic data matches genetic data in a root page (e.g., the new genetic content item) from a trusted network site. A trusted network site is a site trusted for accurate scientific data (e.g., a network site publishing peer reviewed articles). The root page may link to additional network pages on different sites, which can be included for display in the user interface. In some example embodiments, the user data can match genetics data in the root page in different ways (e.g., exact match, statistical match), as discussed in further detail below. In some example embodiments, a visualization (e.g., a chart, a graph, a table) that has been pre-associated with match type is included in the user interface for display to the user. For example, if an exact match occurs a first type of visualization (e.g., a checkbox) is included in the user interface; whereas if a statistical match occurs a second and different type of visualization is included in the user interface. The root page may be hosted or originate from a trusted class of network sites. Pages from the trusted class of network sites (e.g., www.nature.com) may hyperlink to secondary pages from other network sites (e.g., a webpage article on www.wallstreetjournal.com that references the page on www.nature.com).

In some example embodiments, content from the secondary pages is automatically parsed and included in the user interface with the user data, and one or more visualizations. In some example embodiments, the secondary pages may be of an elevated class of network sites, which are trusted but less so than the trusted class. For example, the elevated class may only include webpage articles published on some newspaper websites. In some example embodiments, additional classes are created based on pages of the additional classes linking to the root or secondary pages. In some of those example embodiments, based on the category selected by a user, page content from different classes is included in the user interface. For example, if the genetic variation is in a “fun” category (i.e., not life threatening, such as eye color), and further, if the user data matches the genetic data in the root page, then page content from secondary or tertiary class (e.g., an article from a blog) can be included in the user interface. In contrast, if the genetic variation is more serious (e.g., heart-health related) only page content from the secondary or root pages is included in the user interface, according to some example embodiments.

Attention is now directed toFIG. 1, which illustrates a system100including a genomic services platform104in accordance with the disclosure. As shown, the system100includes a sequencing laboratory110organized to receive biological samples114(e.g., blood, saliva) from users. The sequencing laboratory110may include sequencing equipment111(e.g., next-generation sequencing (NGS) equipment) operative to perform sequencing operations upon the biological samples114in order to determine genomic sequence information corresponding to the users. The resulting genomic sequence information may then be provided to the genomic services platform104for data processing, data storage, and data access. Such users may possess client devices (e.g., client device108, such a smartphone or a laptop computer) storing software applications112downloaded or otherwise obtained from servers operated and provided by partner application providers120. In one example embodiment, the genomic services platform104is operated by an entity having contractual relationships with each of the partner application providers120and may provide such providers with selective access to sets of the user's genomic information stored by the genomic services platform104.

In the embodiment ofFIG. 1, the genomic services platform104may be implemented using “cloud” computing capabilities. Cloud computing may be characterized as a model for facilitating on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. Cloud systems can automatically control resources expended by utilizing metering capabilities with respect to, for example, storage, processing, bandwidth, and active user accounts. Various cloud service models are possible, including cloud software as a service (SaaS), cloud platform as a service (PaaS), and cloud infrastructure as a service (IaaS).

In the embodiment ofFIG. 1, the genomic services platform104may operate on “private” cloud infrastructure provided and managed by one or more third-party organizations. For example, in the embodiment ofFIG. 1the genomic services platform104includes a bioinformatics processing network130operative in a cloud environment managed by a first third-party organization, with the remainder of the genomic services platform104operating on infrastructure (e.g., another subnetwork having a different network address) provided by a second third-party organization. In one embodiment, the bioinformatics processing network130operates within the BaseSpace Sequence Hub provided by Illumina, and the remainder of the genomic services platform104operates through an Amazon® Web Service (AWS) Cloud. In other embodiments, some or all of the genomic services platform104may be implemented using other cloud environments such as, for example, a Microsoft® Azure cloud or another third-party cloud such as DNA Nexus. As shown, the bioinformatics processing network130may include a read alignment module132, a variant calling module134, a variant refinement module138, a quality control module142, and a variant imputation module261.

In other embodiments, the genomic services platform104may be implemented by using on-premises servers and other infrastructure rather than by using cloud-based services. Alternatively, hybrid implementations of the genomic services platform104including a combination of on-premises and cloud-based infrastructure are also within the scope of the present disclosure.

Referring again toFIG. 1, the genomic services platform104includes an application server146that provides a portal through which users may complete a registration process for access to developer applications. In some examples, the application server146has access to a user (or customer) database147. The user database147stores data relating to new and existing users and may be accessed by the application server146for user authorization and credentialing purposes, for example. In some examples, and depending on the services requested, there may be a hand-off of user data to facilitate the co-ordination of services between the genomic services platform104and other partner application providers120(e.g., app developers), other sequencing laboratories110, or generally between entities within the system100.

Through a series of API calls148to an application programming interface (API) endpoint, e.g., Helix™ Application Programming Interface (HAPI), a user's application112can invoke certain tasks at the application server146to be performed by the application server146or in association with other entities within the genomic services platform104. Typically, tasks using this API will relate to updating user data stored in the user database147and may include aspects such as querying data, adding or deleting data, and obtaining metadata about the data. Such applications offered through the portal established by the application server146may be the same as, or different from, the applications offered through the partner application providers120.

The partner application providers120can also interact with the application server146in relation to non-genomic information. Through a series of API calls149to an API endpoint, e.g., Helix™ Partner Application Programming Interface (HPAPI), a partner application provider120can also invoke certain tasks at the application server146, such as querying user data, adding or deleting user data, and obtaining metadata about the user data.

Upon completing the registration process, in one embodiment a registered user is sent a receptacle (e.g., a tube or vial) into which the user may deposit a biological sample114(e.g., saliva). In one embodiment, the user may receive the receptacle via mail or a package delivery service and may send the receptacle containing the biological sample114to the sequencing laboratory110using the same or a similar mode of delivery. As part of the registration process, the user may be assigned a unique identifier (such as a unique “user registration ID”, a “user ID”, a “kitId”, or another identifier described further below) that is imprinted or otherwise included on a label attached to the receptacle for the biological sample114sent to the user. The identifier may be in the form of a bar code for tracking progress of the user's biological sample through the sequencing laboratory110and identifying the user's sample and related information in the bioinformatics processing network130. The labeling associated with the biological samples114sent to the sequencing laboratory110typically lacks any personal information enabling direct identification of the users associated with such biological samples114.

In one embodiment, a user may register via the portal established by the application server146prior to ordering genome-related applications or network services from the partner application providers120. In other embodiments, the user may access or download an application directly from a partner application provider120and provide registration or purchase information that is then forwarded to the genomic services platform104via an API endpoint, e.g., HPAPI. Upon receiving the registration information, the operator of the genomic services platform104may send a receptacle to the user for receiving the biological sample114, which is subsequently sent by the user to the sequencing laboratory110.

Attention is now directed toFIG. 2, which illustrates a flow diagram of operations performed within the system100, according to some example embodiments. As shown, a user may select an application or network service either through the portal provided by the application server146or via a website or the like provided by a partner application provider120(stage210). In response, either the application server146or the partner application provider120may generate an order (stage214), which causes a test kit including a receptacle for a biological sample114to be sent to the user (stage220). The user then provides the biological sample114to the sequencing laboratory110(stage224).

Upon receiving the biological sample114, the sequencing laboratory110prepares the biological sample114for sequencing (stage230). As part of the preparation process, the biological sample114may be placed in a sample preparation cartridge to which reagents or other substances are added pursuant to the preparation protocol utilized. Such preparation of the biological sample114may include, for example, isolating or purifying the biological sample114and performing one or more of cleaving, degrading, annealing, hybridizing, denaturing, or ligating processes involving the biological sample114. These processes may in some examples occur during transit of the biological sample114to the sequencing laboratory110. Any suitable sample preparation operation known to those of ordinary skill in the art may be employed during stage230.

Once the biological sample114has been prepared, it is processed by sequencing equipment111(e.g., NGS equipment) operative to generate observed genomic sequence reads and related quality score information (stage234). The sequence reads generated may correspond to some or all of the user's genome sequence including, for example, genomic DNA, cDNA, hnRNA, mRNA, rRNA, tRNA, cRNA, and other forms of spliced or modified RNA. In exemplary embodiments, the sequence reads may relate to, for example, somatic, germline, gene expression, and transcriptome sequences.

With reference toFIG. 3, in one embodiment, related quality score information and certain metadata generated by the sequencing laboratory110are included within a storage file300(such as a FASTQ file) which is electronically communicated to the bioinformatics processing network130(stage238,FIG. 2). Generally, when sequencing is performed, raw image files are generated that can be used to identify which nucleotide is at a given read area. The FASTQ file format represents the raw read data from the generated images (e.g., 570 megabytes of raw read text data in 7.2 million rows, for a typical user). The FASTQ format can include the sequence string, consisting of the nucleotide sequence of each read, and can also include a quality score for every base. The storage file300, or simply the raw images of sequence reads and related information, may be encrypted at302using one or more conventional techniques prior to being communicated to the bioinformatics processing network130and subsequently decrypted at304. For example, the storage file300may be encrypted with a symmetric key, which may itself be encrypted. In some example embodiments, the storage file300can be encrypted and transferred using an asymmetric key-pair.

As is discussed below, and with reference toFIG. 2andFIG. 3, in one embodiment the bioinformatics processing network130uses this information from the sequencing laboratory110together with population variation data in order to perform the following operations:1. Read Alignment: align the observed sequence reads in a FASTQ file to a reference genome, which may be in a non-FASTQ format (e.g., FASTA) and store the alignments in a file in a format such as a Sequence Alignment Map (SAM) file308format (stage242,FIG. 2), which, while compressed, can still exceed 1.4 GB with 1.4 million lines of text data. The SAM file308can be converted into a Binary Alignment Map (BAM) file306format (e.g., a 7.5 GB text data file), which is a binary representation of the alignment data in the SAM file308.2. Variant Calling: compare the user's genome to the reference genome and identify variants such as single-nucleotide polymorphisms, insertions, and deletions, and store these variants in a file format, such as a variant call format (VCF) file310or a genomic variant call format (GVCF) file312(stage250,FIG. 2). VCF is a file format for storing DNA variation data such as single-nucleotide variants (SNVs), also called single-nucleotide polymorphisms (SNPs), and other variations, such as insertions/deletions (indels), structural variants, annotations, large structural variants, etc. Like FASTQ, SAM, and BAM files, a user's VCF file is often a very large file (e.g., hundreds of gigabytes of text data) having millions of rows, each row having multiple columns or fields of data. Each row of a VCF file corresponds to a variant at one genomic position or region. A VCF file has multiple columns or tab-delimited fields including, for example, a position column that specifies the start of the variant, a reference allele column of the reference genome, and a nonreference allele column comprising the user's allele value, for example.3. Variant Refinement: perform additional processing and filtering to derive the final variant calls (stage254,FIG. 2). In some examples, a ploidy correction is performed during the variant refinement step. Ploidy, in genetics, relates to the number of chromosomes occurring in the nucleus of a cell. A chromosome is a threadlike structure of nucleic acids and protein found in the nucleus of most living cells, carrying genetic information in the form of genes. In normal somatic (body) cells, chromosomes exist in pairs. The condition is called diploidy. During meiosis, the cell produces gametes, or germ cells, each containing half the normal or somatic number of chromosomes. This condition is called haploidy. When two germ cells (e.g., egg and sperm) unite, the diploid condition is restored. Polyploidy refers to cells the nuclei of which have three or more times the number of chromosomes found in haploid cells. Some cells have an abnormal number of chromosomes that is not typical for that organism. In some examples, a ploidy correction is performed by making a sex inference using a heuristic based on the ratio of high-quality reads mapped to chromosome Y divided by those mapped to chromosome X.4. Quality Control: generate a quality control (QC) report314with QC metric values computed on the subject's read alignments and/or variant calls (stage248,FIG. 2).5. Derived Statistics: In one embodiment, statistics316may be derived based upon, for example, sequence reads and/or variant information for use in quality control and process monitoring (stage256,FIG. 2). In some alternative examples, a ploidy correction could be performed in this stage instead by making a sex inference using a heuristic based on the ratio of high-quality reads mapped to chromosome Y divided by those mapped to chromosome X. In some examples, derived statistics are obtained as part of the quality control stage248, such that statistic derivation is not performed as a discrete, subsequent operation.

For each of the observed sequence reads in the FASTQ file, the read alignment module132determines a corresponding location in a reference sequence (or finds that no such location can be determined) (stage242). The read alignment module132may utilize a mapping algorithm to compare the sequence of a given read to that of the reference sequence and attempt to locate a potentially unique location in the reference sequence that matches the read.

The results of the sequence alignment operation may be stored in a relatively compressed format such as, for example, in a compressed BAM file306(stage246) or in a file utilizing another compressed storage format. The resulting BAM file306may, in one example, be indexed relative to the reference sequence (e.g., a SAM file308) and analyzed by the quality control module142(stage248). In one embodiment, the variant calling module134is configured to process the BAM file306or SAM file308to identify the existence of variants such as single-nucleotide variants (SNVs) relative to the reference sequence (stage250). The results of the variant calling process may be stored within, for example, one or more VCF files or in other variant call file formats. In one embodiment, the variant calling module134produces two variant data files, although in alternative implementations only a single variant data file may be produced. The first variant data file (e.g., the GVCF file312) provides general information about all sites in the genome, which include sites both with and without variants (reference calls); the second variant data file (e.g., the VCF file310) does not provide information for reference calls. The second variant data file (e.g., the VCF file310) provides finalized posterior genotype likelihoods for variants (i.e., for each site at which a variant occurs, it gives the probability that the genotype it assigned to the sample at the site is incorrect). The first variant data file (e.g., the GVCF file312) includes genotype likelihoods for variants, but they are riot finalized, as they may be based on incomplete or low-quality information or genotypes. The sequencing and alignment calling process can create many technical artifacts that can lead to inaccurate results. Using various quality metrics computed for the variants, quality filtering is performed on the second variant data file to remove such artifacts. After filtering, the second variant data file is merged with the first variant data file.

In one embodiment, variant refinement (stage254) is performed with respect to variant and reference calls produced during stage250in order to generate a final variant call output of observed variants. As is discussed below, additional variant calls not directly determined by observed results of the sequencing process may be added during a subsequent variant imputation processing step. In some embodiments, for each biological sample114processed during stage254, the variant refinement module138merges the two variant data files generated by the variant calling module134for the biological sample114into a single variant data file, merges records in the file that represent adjacent reference calls, merges records in the file that represent overlapping variant calls or reference calls, performs ploidy correction using derived statistics (stage256), and performs variant filtering. By merging the two files produced by the variant calling module134, the variant refinement module138produces a variant data file with reference calls from the first file and variant calls with posterior genotype likelihoods from the second file. In one embodiment, the variant data file will contain two types of records that can be merged: records representing adjacent reference calls and records representing overlapping variant calls or reference calls.

In some examples, the variant data file containing the refined variant calls produced by the variant refinement module138is stored within a genomic data storage150before variant imputation and may be encrypted using conventional techniques (stage258). In one embodiment, the genomic data storage150is implemented using cloud-based storage such as, for example, Amazon Simple Storage Service (S3), which is available through Amazon Web Services™ (AWS). In general, S3 provides persistent storage for hypertext transfer protocol (HTTP) access to store and retrieve data.

In some examples, haplotype reference data is utilized in the variant imputation operation of stage262(FIG. 2). A reference haplotype can indicate what types of variants are found at given chromosome positions in a sequence. So, if a chromosome position is known, and a variant is detected at that position but the nature or type of the variant is not known (or is known but with a low degree of certainty or probability), reference to the known variants on the corresponding haplotype position can help to complete or “boost” (or impute) the missing information. These variant records including refined and imputed variants may then be encrypted using conventional techniques and stored within the genomic data storage150(stage270) for controlled access by a user or partner application provider120as described below.

In some example embodiments, when a user interacts with an application112obtained from a partner application provider120, the application112may make requests to the partner application provider120which require the partner application provider120to access genomic information stored by the genomic services platform104(stage274). Upon receiving such a request, the partner application provider120may issue a request for the relevant information through a genomics interface160of the genomic services platform104comprising a network interface and a genomics API (stage278). Referring again toFIG. 1, through a series of API calls122to an API endpoint, e.g., Helix™ Genomics Application Programming Interface (HGAPI), at the genomics interface160, a partner application can invoke certain tasks at the genomics interface160such as making requests; querying information; adding, updating, or deleting information; and obtaining metadata (tags) about the information.

The various system APIs discussed herein (more specifically, the example APIs described herein as HAPI, HPAPI, and HGAPI) allow a partner application provider120to integrate genetics into its applications, products, or services. The genomic services platform104supports multiple application providers. The APIs are designed to use consistent resource-oriented URLs as well as HTTP response codes to indicate errors. They also support built-in HTTP features, such as HTTP verbs, for compatibility with the majority of standard HTTP clients. All responses are returned as JSON messages.

Using the APIs, a partner can in some examples access two services based on development needs. Each service has both staging and production endpoints. The two hosted, dedicated services can be invoked to notify a partner application provider of user events and to give the partner access to the relevant genetic information that enables DNA-related features. The first service, for example accessible at the endpoint HPAPI, utilizes the user database147and can notify a partner about a user's status, including aspects such as where the user's biological sample114is in the sequencing process, if they have registered their DNA collection kit, and whether or not they have consented to share their genetic and personal information with the partner's application.

In some examples, the partner API (HPAPI) acts as an interface between the system100or genomic services platform104infrastructure and partner application provider120infrastructure. This service can provide certain non-genomic data a partner may need to enable their app to query genomic data and return results back to a user. In other aspects, the partner API service specifically notifies partners about one or more of the following events: a user has purchased an app and is granting permission for that app to access their genomic data, a user has submitted a saliva sample and that sample is being processed in the lab, a user's sample has completed sequencing and QC (Quality Control) and the genomic data is available to query, a user's genomic data has been updated due to an upgrade or a change in the bioinformatics processing network130, or a user has withdrawn consent and/or has funded or removed an app.

Some embodiments of a sample service within the system100store and serve sample statuses. An example sample service can perform, for example, the following functions: translation of inbound accessioning events from partner application providers120that contain a kitId and a user ID to a sampleId, translation of outbound (sequencing laboratory110) sample statuses (e.g., BaseSpace sample statuses) with a sampleId to be identified with a kitId and a user ID, storage of sample statuses for retrieval, and publishing message queues to HPAPI or directly to partners on sample status updates.

In one example of an account update provided by the first service, a user can agree to share his or her relevant genomic and personal information with a partner application, verify an email address, and register a kit. The registration step can be important as a user purchasing a kit might not be the one submitting it. At the time of purchase, a kit will be sent in the mail and eventually a user will register that kit. Since the purchaser may be a different person from the sample provider, the user who delivers genetic data via the spit tube in a kit is not confirmed until that user registers the kit as their own.

The second service, for example accessible at the endpoint HGAPI, can be used to request the relevant genetic information that enables the partner's DNA-relevant features in its application. Accessing a user's variants (or markers), for example, is typically a primary use of this service. In some examples, a “no-call” is issued when the genomic services platform104is unable to make a call that meets a minimum quality threshold due to lack of coverage or poor fit of the probabilistic variant calling model. A no-call is characterized by the presence of a specific entry, such as “−1”, in the genotype array. In some examples, a “reference” call is issued when the genomic services platform104observes, in sufficient quantity and with sufficient quality, only bases matching the reference sequence. A reference call is characterized by the presence of only “0” entries in the genotype array. In some examples, a “variant” call is issued when the genomic services platform104observes, in sufficient quantity and with sufficient quality, bases not matching the reference sequence. A variant call is characterized by the presence of any element in the genotype array greater than 0, representing the presence of an alternative allele present in alternate bases. If the record is not a no-call or a reference call, then it is a variant call.

In some examples, an access token (e.g., an OAuth access token) is needed any time a partner application calls a system API to read a user's information. When a partner requests an OAuth access token, it is required to define token parameters, such as grant type and scope. A partner will need credential pairs to continue, which can be generated by performing appropriate credentialing steps. All API requests are made over HTTPS. Calls made over plain HTTP will fail. API requests without authentication will also fail.

In some example embodiments, a request for relevant information from a partner application provider120includes a unique ID (“PAC ID” or user ID) that identifies a binary tuple of the form (app, user where “app” is a value identifying one of the applications112for the partner application provider120, and “user” is a value identifying the particular end user interacting with the application112corresponding to the app. In some examples, the PAC ID may comprise a three-part tuple in the form of (partner, app, user) with corresponding values identifying a partner application provider120, an application112, and a user. Other combinations of values are possible, such as (partner, app). Irrespective of which PAC ID is used, an objective of a PAC ID is to allow a partner application provider120to refer to a user without knowing the actual “value” of the user and to maintain anonymity and privacy in health records. Upon receiving the request including the PAC ID, the genomics interface160may present it to a variant storage module154.

In one embodiment, the variant storage module154operates on a server-less framework in a cloud environment, such as Amazon Web Services (AWS Lambda). The AWS Lambda system allows the variant storage module154to run code without provisioning or managing servers. The variant storage module154accrues costs only for the compute time it consumes when running its functions. There is no charge when the code is not running. This can be important because call volume demands tend to be highly variable. In some examples, the variant storage module154receives in excess of one thousand requests per minute for information. The server-less arrangement is highly scalable and minimizes running costs for the variant storage module154, and indirectly for partners and users. Using AWS Lambda, the variant storage module154can run code for virtually any type of partner or user application or backend service with very minimal or zero administration.

In some examples, the variant storage module154performs automated tests. The tests are run for any code change that must pass the tests before being deployed to production. For a given PAC ID, the variant storage module154may create and output a file and send to HGAPI an expected result that may be investigated if incorrect. In another example, a test BED file downloaded from a mapping service164is checked for conformity with an expected result. Other automated tests include checking that a request without a user ID (e.g., PAC ID) or app ID, or having a bad PAC ID or app ID, fails. Some data files used within the system100may be in a binary variant call format (BCF, or a BAM file described elsewhere herein), and each user may have an associated BCF. Given a BCF, further automated testing may check that filtering by a given region returns correct or expected test intervals, or does not contain a given interval. Other testing may check, again, given a BCF, that an open boundary condition is correctly handled, or that overlapping regions are correctly handled, or that compared to a converted VCF, certain results are expected. Other automated tests may include checking that a BED file can be opened correctly, or that if it cannot be opened correctly, an error message is returned. Other testing may check for attempts to open non-existent BED files, or check connectivity with the mapping service164such that given an invalid App ID and/or PAC ID, no BED file is returned. Other tests include reference block trimming, for example checking that a returned interval is always a subset of the applicable sequence region, or that a reference block that overlaps multiple regions returns correctly each restricted overlapping region. In some examples, the data used for automated tests is dummy data that mimics what real data will look like in production. In other examples, the test data is derived from real biological samples (cell lines) and modified to be used for testing.

FIG. 4displays an example Browser Extensible Data (BED) file400that defines specific regions of a genome. The file400includes three fields that define a chromosome402, a start position404, and an end position406in the genome. Various conventions may be utilized to specify these locations. In some examples, a BED file168includes definitions of multiple “DNA windows” defining regions (e.g., one or more ranges of reference locations) of a user genome that may be requested by a particular partner application provider120or application112through the genomics interface160.

For example, upon a request for user genomic data from a partner application provider120being received via the genomics interface160, the variant storage module154retrieves all the variants pertaining to a user's genome and filters these based upon the PAC ID and the appropriate DNA window specified in the BED file168. The fetched variants are then returned via a secure connection to the requesting partner application provider120, and potentially stored by the requesting partner application provider120in an optional genomic datastore121. This enables the partner application provider120to deliver corresponding variant data to the application112responsible for initiating the request for genomic information in a controlled and secure manner. The content of the corresponding variant data will generally be dependent upon the nature of the application112. In this way, a user's genetic information can be sequenced once, stored indefinitely, and then queried again, potentially many times, to provide further biogenetic information in a secure manner.

Further details regarding selective access to user genomic data are found in Application Ser. No. 62/535,779, titled “Genomic Services Platform Supporting Multiple Application Providers”, filed on. Jul. 21, 2017, which is incorporated by reference in its entirety.

Attention is kindly directed toFIG. 5, which shows an example data hierarchy500and additional data structures, according to some example embodiments. InFIG. 5, a genome-wide association study (GWAS) database505stores data from one or more genome-wide association studies. Generally, genome-wide association studies are conducted by leading researchers to compare the genotypes of large numbers of individuals to identify genetic variant data correlated with different genetic traits/expressions (e.g., diseases, the ability to smell methanethiol after eating asparagus, etc.). The GWAS database505can contain entries for different studies published on a variety of different websites. In some example embodiments, a given root page may contain a link or entry referring to a GWAS data store (e.g., the GWAS database505). In some example embodiments, one or more websites are preselected as being trusted sources of genomic data (e.g., www.nature.com). Pages that are hosted on the sites preselected as being trusted are root pages510, in some example embodiments, the genomic update system700stores the preselected websites and retrieves, from the GWAS database505, only pages published on the preselected websites, such as one or more of the root pages510. The websites are preselected because they are of a trusted class of network sites. Each of the root pages510of the preselected websites can comprise genetic variation data, such as genetic data515.

FIG. 6shows example data structures600, according to some example embodiments. As illustrated a variant identifier605(e.g., a location specified within a BED file) is a key or an identifier of a genetic variation, such as a single-nucleotide polymorphism (SNP) or multiple-nucleotide variant (MNV). The variant identifier605identifies a genetic variation of genetic material, such as a chromosome615of the user. The variant occurs at a specific location610on the chromosome615. In some example embodiments, the variant identifier605does not directly reference the location610. In those example embodiments, the variant identifier605can be used as a lookup value to determine the variant location (e.g., start and stop positions within a BED file, as shown inFIG. 4). The variant identifier605is associated with expected variant values620(e.g., “A/G” alleles) which include the reference sequence as well as expected differences from the reference sequence.

A user who has their genetic data sequenced and stored in the genomic data storage150can compare their user variant values625to the variant values620of the variant identifier605to determine whether the user variant values625match the variant values620of the genetic variation identified by the variant identifier605. As discussed in further detail below, the user variant values625need not exactly match the variant values620for the user to exhibit the phenotype identified by the genetic variation of the variant identifier605. For example, a study discussing the genetic variation of the variant identifier605may explain that if the user contains a single variant value of “G” (e.g., “A/G”) the user may have an increased likelihood (e.g., 45%) of expressing the phenotype of the genetic variation, and a significant likelihood (e.g., 55%, 80%, 90%) of expressing the phenotype if the user contains two copies of the variant value “G” (e,g., “G/G”). However, even if the user variant values625do not exactly match the variant values620, there still may be a significant statistical likelihood (e.g., 45%, 80%) that the user will express the phenotype of the genetic variation.

Continuing the example with reference toFIG. 5, if the user data530is of a first match type (e.g., an exact match), a first visualization520(“VIZ 1”) is included in a user interface540. On the other hand, if the user data530is of a second match type (e.g., a statistical match), a second visualization525(“VIZ 2”) is included in the user interface540. Additional visualizations likewise may be implemented, each type being pre-associated for inclusion in the user interface540based on a match type between the user data530and the genetic data515.

As mentioned above, the root pages510are trusted because they are published to servers that have been preselected as scientifically trustworthy (e.g., nature.com). Additional classes of pages hosted on other servers can be included in the data hierarchy500. Further, content from those additional classes of pages can be included in a display if those pages have one or more links that point back to a root page510. For example, with reference toFIG. 5, one or more of the root pages510may have links to secondary pages535that reference or link back to a given root page510.

For example, “PAGE 3” of the root pages510may have links to all three secondary pages535, which may be pages of an elevated class (e.g., pages from certain newspaper websites). In some example embodiments, the secondary pages535are identified via spidering hyperlinks of a public network (e.g., the Internet) to determine which public network pages link to a given root page. Further, in some example embodiments, each root page510is parsed to extract link information to one or more secondary pages535. For example, “PAGE 3” can be HTML parsed or “scraped” to identify network links to “LINKED PAGE 1”, “LINKED PAGE 2”, and “LINKED PAGE 3”. In some example embodiments, if genetic data515from “PAGE 3” matches the user data530, then one or more items of content from the secondary pages535are included in the user interface540for display with a visualization, such as the first visualization520(“VIZ 1”).

Further, in some example embodiments, content from tertiary pages545that link to the secondary pages535can also be included in the user interface540if the user data530matches the genetic data515included in a root page510, and further if a page in the tertiary class links to a page in the secondary class, that in turn links to a root page. For example, if genetic data515from “PAGE 3” (in the root pages510) matches the user data530, and if “PAGE 3” links to “LINKED PAGE 3” which further links to “FURTHER PAGE 3” (e.g., a blog, vlog, tabloid webpage, etc.) then one or more items of content from “FURTHER PAGE 3” are included in the user interface540.

FIG. 7shows example internal functional engines of a genomic update system700, according to some example embodiments. The genomic update system700may be hosted and run by the application server146in the system100. However, in some example embodiments, the genomic update system700may be entirely run by a user device, such as the client device108, or by a partner application provider120(e.g., a server managed by the partner application provider120). Further, select engines of the genomic update system700may run on different devices, as discussed in further detail below with reference toFIG. 14.

As illustrated, the genomic update system700comprises a database engine705, a site engine710, a correlation engine715, a content engine720, an interface engine725, and a trait engine730. The database engine705is configured to access a database of genomic data, such as a database storing genome-wide association study (GWAS) data. In some example embodiments, the database that database engine705accesses is stored internally in the genomic services platform104(e.g., in a partition of the genomic data storage150).

In other example embodiments, the database that the database engine705accesses is an external database that is programmatically accessible over a network using an API. In those example embodiments, the database engine705is configured to periodically poll or query for new updates to the external database. For example, the database engine705can be configured to query the database for updates from sites that have been preselected as trusted sites (e.g., nature.com, PLoS.com, sub-domains thereof, etc.), secondary sites, tertiary sites, and so on, as discussed above with reference toFIG. 5. In some example embodiments, the database engine705is configured to store selections received from an administrative user of the system100indicating which sites are preselected sites. In those example embodiments, the database engine705may maintain its own internal database such that the database only contains entries of network pages from preselected sites. Further, in some example embodiments, such as those using an external genomic database (e.g., an external GWAS database), the database engine705is configured to generate a query that specifies that only network pages from the preselected network sites should be returned as query results.

The site engine710manages accessing the network pages identified by the database engine705from the genomic database, according to some example embodiments. In particular, for example, the site engine710may access or otherwise download the pages identified by the database engine705and extract data from the network pages. In some example embodiments, the site engine710is configured to extract one or more items of variant data (e.g., variant values620, variant identifier605, descriptive data that describes the genetic variation, etc.) of genetic variations described in the network pages. Further, in some example embodiments, the site engine710is configured to parse the network pages to extract network link data (e.g., hyperlinks) to pages that reference or mention a given network page, as described in further detail below.

The correlation engine715is configured to compare the variant values of the genetic variation reported in a given network page to the user's variant values to determine whether the user's variant values exactly match the reported variant values, or statistically match the reported variant values.

The content engine720is configured to access and load additional network pages or content that is linked to the network pages, as discussed in further detail below. In some example embodiments, the content engine720can generate a summary of the linked content or selection of a linked additional network page for inclusion in the user interface for display on the client device. For example, the content engine720identifies a first paragraph in the linked additional network page and stores the first paragraph for inclusion in the user interface for display on the client device. Further, in some example embodiments, the content engine720is configured to identify a preselected visualization for inclusion in the user interface. In some example embodiments, the preselected visualization is pre-associated with the type of match identified by the correlation engine715.

The interface engine725is configured to transmit network page data (e.g., pages of preselected sites), additional network page data (e.g., additional pages linked to the network pages), summarizing data (e.g., genetic variation data of the user), and/or other data to a client device for display on a display screen of the client device. Further, in some example embodiments, in addition to the data values for display, the interface engine725transmits user interface markup language (e.g., HTML layout data, CSS data) for display within the client device (e.g., by a web browser). In other example embodiments, the interface engine725transmits only the data values and riot display/layout data, and the client device has native functionality for displaying the content in a user interface of an app, such as an application112(FIG. 1).

The trait engine730is configured to manage correlations between network services (e.g., an application provided by the partner application provider120) and pages published to a network site (e.g., a nature.com article). For example, when a newly published network page is identified, the trait engine730can identify one or more network services based on content in the network page and transmit a user interface including links to the network services to a client device.

FIG. 8shows example internal functional components of a client device application112(e.g., a mobile application), according to some example embodiments. As illustrated, the client device application112comprises a user interface engine800and a client-side network interface engine805. The user interface engine800is configured to generate one or more user interfaces on the client device application112. In some example embodiments, the user interfaces can include display elements such as selectable buttons (e.g., category buttons), scrollable windows (e.g., a newsfeed), images, text data, links to other user interfaces generated by the user interface engine800, and/or links to external network sites.

The client-side network interface engine805is configured to programmatically interact with the interface engine725(e.g., an API) of the genomic update system700. For example, the client-side network interface engine805running on the client device application112may receive genomic data of the user including network page data, visualizations, and/or content to display. In some example embodiments, the client-side network interface engine805receives raw data (e.g., no display/layout data) from the genomic update system700and transfers the data to the user interface engine800. In those example embodiments, the user interface engine800is configured to generate user interfaces and populate data fields or areas of the user interfaces with the raw data received from the client-side network interface engine805. Alternatively, the client-side network interface engine805receives raw data with display data (e.g., browser markup language) to generate a user interface on the client device108(e.g., a laptop's web browser), according to some example embodiments.

FIG. 9shows a flow diagram of a method900for generating a genomic update user interface, according to some example embodiments. At operation905, the database engine705identifies database entries in a genomic database. For example, at operation905, the database engine705queries an external GWAS database for updates. At operation910, the database engine705filters the database entries. For example, the database engine705filters out network pages based on one or more criteria (e.g., filters out pages that do not originate from preselected servers). In some example embodiments, the GWAS database is an internal GWAS database that is customized to store only network pages from preselected servers. In those example embodiments, operation910may be skipped or otherwise omitted.

At operation915, the site engine710accesses the network pages from the database results. For example, the database engine705may return a database update that indicates that one of the preselected servers has published a new network page describing a genetic variation discovery. In those example embodiments, the site engine710identifies a hyperlink to the network page hosted on the preselected server and downloads or otherwise accesses the network page for extraction of genetic variation data and network link data, as described in further detail below.

At operation920, the correlation engine715compares the variant value data of the downloaded network page to the user's variant values from the genomic data storage150to determine whether the user's variant values match or otherwise satisfy the variant values reported in the network page, as described in further detail below.

At operation925, the content engine720determines or otherwise identifies pages linked to the network page. For example, the network page that is downloaded from the preselected server may include one or more hyperlinks to websites that host pages that discuss or otherwise mention the network page from the preselected server. The content engine720may use HTML scraping or parsing to extract the link information and load the pages that are linked to the network page of the preselected server. In some example embodiments, the content engine720is configured to extract one or more portions of text (e.g., an abstract, an introduction paragraph) from the additional pages for inclusion in a genomic update user interface on the client device108, as discussed in further detail below.

At operation930, the user interface engine800generates a user interface comprising the network page data from the preselected servers, content from the additional pages that link to the network page that are not hosted by the preselected servers, one or more visualizations, and genetic data, as discussed in further detail below. At operation935, the user interface engine800displays the user interface on the display device (e.g., a touchscreen display of a smartphone) of the client device108.

FIG. 10shows a flow diagram of a method1000for identification and storing of variant data from a network page of the preselected server, according to some example embodiments. The operations of the method1000may be implemented as a subroutine of operation915of the method900in which network pages hosted on preselected servers are accessed and parsed for variant data. In some embodiments, multiple network pages from preselected servers are identified at operations905and910of the method900. In the example ofFIG. 10, the method1000is configured to loop through each page and store variant data (e.g., with reference toFIG. 6, one or more variant identifiers such as the variant identifier605, and one or more variant values such as the variant values620) for analysis in comparison to user variant values. At operation1005, the site engine710loads a network page from a preselected site. For example, at operation1005, the site engine710downloads a webpage of a journal article from a trusted scientific website.

At operation1010, the site engine710identifies variant data in the loaded page. For example, at operation1010, the site engine710performs a keyword search for genetic variation identifiers (e.g., a reference SNP identifier (RSID) of an SNP variation). In some example embodiments, at operation1010, the site engine710searches a loaded page for the variant identifier data by searching for alphanumeric data in a pre-specified format. For example, at operation1010, the site engine710may search the loaded page for an alphanumeric term comprising two letters (e.g., “rs”) followed by at least four integers. Further, at operation1010, the site engine710identifies the underlying variant values of the identified genetic information. At operation1015, the site engine710stores the extracted variant data in a database such as the genomic data storage150. At operation1020, the site engine710determines whether there are additional network pages of preselected servers that were identified or otherwise returned as query results from a database (e.g., a GWAS database). If there are additional pages for parsing, the method1000loops to operation1005for parsing of additional pages. After the pages in the return set have been parsed, the subroutine terminates or otherwise returns to the method900ofFIG. 9.

FIG. 11shows a flow diagram of a method1100for determining matches of user variant values to variant values of network pages of preselected servers (e.g., root pages), according to some example embodiments. The operations of the method1100may be implemented as a subroutine of operation920inFIG. 9. At operation1105, the correlation engine715identifies user variant values. For example, at operation1105, the correlation engine715identifies the variant identifier (e.g., an RSID, such as the variant identifier605) and determines the relevant location of the variants on the user's genome using the variant storage module154. The correlation engine715then requests and receives the user variant values (e.g., the user variant values625,FIG. 6) for comparison.

At operation1110, the correlation engine715identifies the variant value data of a root page of a preselected server. For example, at operation1110, the correlation engine715identifies variant values620(FIG. 6) that have been parsed from one of the root pages of the preselected servers. At operation1115, the correlation engine715determines whether the user variant values match the variant values from the root page of the preselected servers. As discussed, matching can include an exact match or a statistical match. If the user's variant values do not match the root page's variant values, then at operation1120the correlation engine715loads the next root page and the method1100loops to operation1110until the user's variant values match a given root page's variant values.

At operation1115, if the user variant values match variant values of a root page, the correlation engine715adds the root page data (e.g., address, variant data, etc.) to the return set at operation1125. At operation1130, the correlation engine715determines whether there are additional root pages for analysis. If there are additional root pages for analysis, the method1100loops to operation1120in which the next root page is loaded for comparison to the user's variant values. In this way, the method1100loops through all the network pages until all root pages that have variant values that match a user's variant values have been added to the return set.

FIG. 12shows a flow diagram of a method1200for identifying page content for inclusion in the genomic update user interface, according to some example embodiments. The method1200can be implemented as a subroutine of operation925of the method900inFIG. 9. If implemented as a subroutine, the method1200starts with a start block and ends or otherwise terminates with a return block in which data is stored for processing in the method900. At operation1205, the content engine720identifies the return set of pages that were determined by the correlation engine715to match the user variant values, as discussed above with reference toFIG. 11. At operation1210, the content engine720identifies one of the root pages in the return set. For example, at operation1210, the content engine720accesses or downloads a given root page in the return set from a network server that hosts the root page (e.g., www.nature.com). At operation1215, the content engine720determines whether the identified root page contains network links to additional pages, such as secondary pages535(FIG. 5) that are hosted on servers that are not in the preselected server set. If the identified root pages do not contain additional links, the next root page in the return set is loaded at operation1220and the method1200loops to operation1210until a root page having additional links is identified. In some example embodiments, the additional links are identified using markup language layer parsing (e.g., page scraping, HTML page scraping, XML page scraping, or markup tag analysis).

At operation1225, the content engine720stores the linked pages or portions of the linked pages in a display set. For example, at operation1225, the content engine720may store the content of a given linked page, such as the first paragraph, for use as a summary or introduction for an item of content in a user interface. At operation1230, the content engine720determines whether there are additional root pages for link identification and content parsing. If there are additional root pages for processing, the method1200continues to operation1220in which the next additional root page in the return set is processed. If there are no additional root pages for processing, the method1200terminates or otherwise stores data for return to the method900.

FIG. 13shows a flow diagram of a method1300for identifying content for inclusion in a genomic update user interface, according to some example embodiments. The method1300can be implemented as a subroutine of operation925of the method900inFIG. 9. If implemented as a subroutine, the method1300starts with a start block and ends or otherwise terminates with a return block in which data is stored for processing in the method900.

At operation1305, the content engine720identifies the return set, which comprises one or more root pages, and the display set, which comprises pages that link to one or more of the root pages. At operation1310, the content engine720determines whether each of the root pages is associated with a linked page. If a given root page does not have an associated linked page (e.g., the root page does not link to a linked page, or no published webpage links or references the given root page), the content engine720defaults and, in operation1320, stores the one or more root pages for inclusion in the user interface. In this way, even if a given genetic variation does not have additional linked pages (e.g., a newspaper article, a blog page), the user interface can at least include data content from the root page as a default mechanism.

In contrast, at operation1310if a given root page is linked or otherwise associated with one or more linked pages, the content engine720stores the linked pages for inclusion in the user interface at operation1315. In some example embodiments, even if a root page is associated with a linked page, the root page is nonetheless included in the user interface at operation1320. Further, in other example embodiments, if a root page is associated with a linked page, the method1300skips to operation1325and the root page is not included in the user interface presented to the end user,

At operation1325, the content engine720determines how the user variant values match the variant values described in the root page. For example, if the user variant values exactly match the variant values described in every page, a first type of visualization (e.g., a checkbox) may be included in the user interface for display with the genetic variation data in the linked page. As an additional example, if the user variant values do not exactly match the variant values in the root page but nonetheless a significant portion of the population (e.g., a population of people discussed in a study) exhibits the phenotype described by the variant values in the root page, the match type is nonetheless considered statistically significant, and a different visualization communicating the uncertainty or likelihood of phenotype expression can be included in the visualization user interface at operation1330(e.g., a pie chart, a bar chart, a side-by-side comparison of a given population's average value and the user's value).

FIG. 14shows a network interaction diagram1400implementing a genomic update user interface, according to some example embodiments. The operations on the left, side of the dotted line are performed by the client device108, whereas the operations on the right side of the dotted line are performed by other network devices, such as the application server146or third-party network servers (e.g., partner application providers1201−N). At operation1405, the user interface engine800(that is executing on the client device108) receives an update instruction. For example, a user of the client device108selects a button or performs a gesture that triggers a genomic update operation. At operation1410, the client-side network interface engine805generates a genomic update request and transmits the genomic update request to the interface engine725(that is executing on the application server146). In some example embodiments, the request generated at operation1410includes a user identifier (e.g., user account data) but does not include any of the user's genetic data and/or data that can be used to identify the user. In some example embodiments, the communications between the client device108and the application server146are encrypted through one or more encryption mechanisms (e.g., HTTPS, application level encryption) to ensure user privacy.

In response to the request, at operation1415, the database engine705queries a genome database (e.g., a GWAS database). As discussed above, in some example embodiments, the database queried by the database engine705is an internal database that comprises only root pages from preselected servers in a trusted class. In those example embodiments, the query can request any update to the internal database. Further, as discussed above, in some example embodiments, the database engine705queries an external database that stores genomic variant data for any updates of root pages that originate from servers that are in the preselected class (e.g., the database engine705queries for any newly published pages to nature.com). At operation1420, the correlation engine715identifies user variant data (e.g., the user variant values625,FIG. 6). At operation1425, the correlation engine715determines whether the user's variant data match any of the variant values of the genetic variations described in the root pages. At operation1430, the content engine720identifies linked pages that link back to or otherwise reference any of the root pages. As discussed above, in some example embodiments, the linked pages are identified via links included in a given root page. Further, in some example embodiments, the linked pages are pages that are found through spidering a public network (e.g., the Internet). In some example embodiments, the additional pages in a secondary elevated class or a tertiary class are submitted by third parties for validation by the content engine720. For example, a partner application provider120can submit a page of content that references a secondary elevated-class page or a root page. In those example embodiments, the content engine720can determine whether the submitted page of content links publicly on the Internet to one of the root pages or secondary elevated-class page. If so, the submitted page can be included in the user interface, according to some example embodiments. At operation1435, the interface engine725transmits the genomic content through a secure channel to the client-side network interface engine805executing on the client device108.

At operation1440, according to some example embodiments, the user interface engine800filters the received items based on categorical selections from the user, or default categorical selections. For example, if the user account data indicates that the user is below a certain age, one or more items of content in a class may be filtered out. For instance, if the user is below 12 years old, a more technical scientific article in a secondary elevated class may be filtered out at operation1440. At operation1445, in response to the update instruction received at operation1405, the user interface engine800displays the genomic content in a genomic update user interface on the client device108.

FIG. 15shows an example genomic update user interface1505, according to some example embodiments. As illustrated in the example ofFIG. 15, a user1500is holding a client device108having a touchscreen display1510currently displaying the genomic update user interface1505. The genomic update user interface1505comprises one or more items of old content1515(e.g., content that was retrieved and displayed during past genomic update operations). The genomic update user interface1505further includes category selection elements1525. The category selection elements1525include a fun category that has been selected by the user1500and a more serious heart-related category. In the example ofFIG. 15, the user1500generates the instruction to retrieve genomic updates for the fun category by performing an input operation, such as a gesture1520, by swiping down on the touchscreen display1510.

Turning toFIG. 16, in response to the user's genomic update instruction, a genome database1600is queried by the database engine705for updates. As displayed inFIG. 16, the genome database1600comprises entries1605-1620. Each of the entries1605-1620can correspond to a root page published on a site, such as a preselected site. For example, the entry1605may be an entry in the genome database1600that links to a root page that originates from a preselected site, such as nature.com, while the other entries1610to1620may not be pages published by or otherwise originating from a preselected network site.

FIG. 17shows an example root page1700that can be accessed or otherwise loaded by the site engine710. As illustrated, the root page1700is a scientific article comprising genetic variation data1705that is buried in complex scientific text (in the genetic variation data1705, the “RS” in “RS3975778” may be listed in lower case, e.g., “rs3975778”, according to some example embodiments). The root page1700further includes additional links1710, which are network links to additional pages such as pages from an elevated secondary class or tertiary class, as discussed above.

FIG. 18shows an example of a linked page1800that links to a root page, according to some example embodiments. As discussed above, in some example embodiments, the content engine720may identify the linked page1800based on a link extracted from the root page, or through spidering and/or other means (e.g., a third-party submission). In the example ofFIG. 18, the linked page1800comprises a hyperlink1805that comprises an address link to the root page1700, according to some example embodiments. The content engine720may store the address of the linked page1800, images of the linked page1800, or portions of text in the linked page1800(e.g., an introductory paragraph, an abstract) for inclusion in the user interface.

FIG. 19shows an updated genomic update user interface1505, according to some example embodiments. As illustrated, in response to the user1500issuing the genomic update instruction, updated user interface content1900is generated on the client device108. The updated user interface content1900may contain a title1905of the linked page1800, an excerpt1910of the linked page1800, a genetic variant identifier1915(from the root page1700), user variant data1920, variant data1925(from the root page1700,FIG. 17), and a visualization1930(e.g., a pie chart) that has been selected based on how the user variant data1920matches the variant data1925. The updated user interface content1900can further include a communication element1935that is configured to generate an electronic message for transmission to a medical professional. The generated electronic message may include data from the root page1700and user data (e.g., user variant values). In some example embodiments, the genomic update user interface1505is configured as a scrollable newsfeed in which multiple items of content can be more readily navigated by the user1500using the client device108in one hand.

As discussed above with reference toFIG. 7, the trait engine730manages identifying genomic content based on genetic variation data included in root pages or GWAS database items. Genomic content includes root pages, pages linked to the root pages, and network services, according to some example embodiments. The network services can include applications provided, hosted, or otherwise accessed through partner application providers (e.g., the partner application providers120). The partner application providers have selective access to different portions of user genomic data to provide visualizations and advanced analysis of accessible portions of a given user's data. Which network service is associated with a given network page can depend on a type of access granted to or analysis provided by the network service. In some example embodiments, when a user's data is sequenced and stored in the genomic data storage150, the trait engine730can identify one or more network services for inclusion in a user interface. In some embodiments, the trait engine730identities network services via a database, such as a trait data structure2000, as displayed inFIG. 20A.

The trait data structure2000includes trait categories2010-2035, which group similar observable traits (e.g., phenotypes). For example, trait category2010is a lung trait category comprising subcategory2010A (asthma-specific genetic traits), subcategory2010B (breath-holding-specific genetic traits), and subcategory2010C (photic-sneeze-specific genetic traits). Likewise, trait category2015is a hair trait category comprising subcategories2015A-2015C for different hair-specific genetic traits, and trait category2020is a blood trait category comprising subcategories2020A-C for different blood-specific genetic traits. Further, trait category2025is a brain trait category comprising subcategories2025A-C for different brain-specific genetic traits, and trait category2030is a skin trait category comprising subcategories2030A-C for different skin-specific genetic traits. Further, according to some example embodiments, trait categories can comprise ancestry or inheritance data (e.g., ancestry origins data, haplogroup data, ancient genomes data). For example, trait category2035is an ancestry-related category including trait data of different genomes, such as genome subcategories2035A-C.

Each of the categories in the trait data structure2000can be associated with metadata items and content items, as illustrated in expanded category data2050(FIG. 20B), which shows expanded associations of the trait category2010(the lung category). Each of the subcategories can be associated with root pages, additional pages that link to the root pages, and one or more network services. For example, subcategory2010A is an asthma category, which links to a root page2052(e.g., a study in a webpage from preselected servers), an additional page2054(e.g., a news website article page) that links to the root page2052, and multiple network services2056which are network links to partner application providers120.

The other subcategories that link to trait category2010likewise have associated items that are related to lung-specific traits. For example, subcategory2010B is a breath-holding category that is associated with a root page2058(e.g., a study hosted on preselected servers) describing a potential genetic predisposition for the ability to hold one's breath for long periods of time, an additional page2060(e.g., a blog article) that links to the root page2058, and an associated network service2062(e.g., a network link to a partner application provider network site). Likewise, subcategory2010C is a photic sneeze category describing a genetic trait or phenotype of sneezing in response to light changes. Subcategory2010C is associated with a network service2064, and further associated with a curated content item2066(discussed below), which describes a study2068(a root page).

Each of the categories can have metadata tags that can be implemented to filter suggested network services or content items based on user selections input via the category selection elements1525(FIG. 15). For example, if a user selects a sports category, then items from subcategory2010A or2010B are included in the user interface, as those subcategories both have sports metadata tags. Further, top-level categories, such as trait category2010, can include metadata tags. For example, as illustrated inFIG. 20B, trait category2010can have a sports metadata tag. If a user selects a sports category, then all underlying subcategory items (e.g., the multiple network services2056, the study2068) can be included in the user interface.

In the example illustrated inFIG. 20B, a single root page and a single additional page are associated with each subcategory. It is to be appreciated that each subcategory can be further associated with additional previously generated items, such as existing items2080, which may include existing root pages and additional pages that link to the root pages. The existing items2080may be automatically included in a user interface when the multiple network services2056are included in the user interface, according to some example embodiments.

In some example embodiments, a subcategory is further associated with curated content that summarizes or explains an associated root page in non-scientific language. For example, with reference to subcategory2010C, the root page is the study2068, which has been associated (via the subcategory2010C) with the curated content item2066. The curated content item2066comprises content that explains the study2068in simpler language (e.g., summarizing language, non-scientific language, etc.). In some example embodiments, when the network service2064(also associated with subcategory2010C) is included in the user interface, the curated content item2066is also included in the user interface.

FIG. 21shows a flow diagram of a method2100for generating a user interface comprising network service links that are related to a user's genetic data, according to some example embodiments. At operation2105, the trait engine730identifies a network page. For example, at operation2105, the trait engine730identifies a newly published root page or new GWAS entry. At operation2110, the trait engine730identifies a trait category (e.g., trait category2010, subcategory2010A) of a genetic variation described in the network page identified at operation2105. At operation2115, the trait engine730identifies items associated with the trait category. For example, at operation2115, the trait engine730accesses the trait data structure2000to identify an additional page that network links (e.g., hyperlinks) to the root page, and further to identify one or more network services associated with the trait category.

At operation2120, the correlation engine715identifies user data in the network page identified at operation2105. At operation2125, the trait engine730generates a user interface that includes user data, network links to network services, and associated content, such as a brief description of the root page's content or the additional page's content.

FIG. 22shows a flow diagram of a method2200for identifying network services related to genetic data of a user, according to some example embodiments. The operations of the method2200can be implemented as a subroutine of operation2115in which items of the trait category are identified. At operation2205, the trait engine730identifies a trait specified in the network page. The trait can be a specific genetic variation or expression thereof (e.g., phenotype) associated with a category. For example, at operation2205, the trait engine730identifies subcategory2010A which is related to asthma-related traits. At operation2210, the trait engine730identifies a network service associated with the category. For example, at operation2210, the trait engine730identifies multiple network services2056associated with subcategory2010A. At operation2215, the trait engine730identifies trait content associated with the trait category. For example, at operation2215, the trait engine730identifies an additional page2054or a summarizing description of content in the additional page2054.

At operation2220, the trait engine730identifies network services that are related to the trait. The network services can be related in that, while they do not provide analysis of the specific trait, they are in the same trait category. For example, at operation2220, the trait engine730determines that subcategory2010A is a child of trait category2010and that subcategory2010B is a sibling of subcategory2010A as both are included in trait category2010. The trait engine730can then identify the network service2062of subcategory2010B as related. The identified related network service can be included in the user interface for display as relevant. At operation2225, the trait engine730identifies related content. For example, at operation2225, the trait engine730identifies the additional page2060which is associated with the different trait subcategory (i.e., subcategory2010B). After operation2225, the method2200terminates and returns identified content to the method2100inFIG. 21.

FIG. 23Ashows an example genomic network service update user interface2310, according to some example embodiments. As illustrated in the example ofFIG. 23A, a user2300is holding a client device108having a touchscreen display2305currently displaying the genomic network service update user interface2310. The genomic network service update user interface2310comprises a window2315generated in response to a root page being published on one of the preselected servers. The window2315comprises content2320including, for example, a title and subheading with a link (“READ MORE”) to an additional page linked to the root page. The window2315further comprises a comparison2325of the user's variant values to the variant values described in the root page. Further, in some example embodiments, the window2315includes an interpretive description2340, which summarizes or gives context to the comparison2325. In some embodiments, interpretive descriptions are created from the root page or additional page (e.g., by extracting a sentence from the root page, or generating custom curated content from the root page or additional page) and linked to the trait category with which the root page is associated in the trait data structure2000. In those example embodiments, when the data of the comparison2325is displayed to a user, an interpretive description can be automatically included. The user2300can then access further analysis of the data displayed in the comparison2325by selecting a network link2345, which directs the client device108to a network site of a network service associated with the trait category used to generate the window2315. Further, a different network service is linked via a network link2350. The network service of the network link2350is not in the same specific category (e.g., a subcategory for caffeine sensitivity) but is related through a parent category (e.g., food-related genetic variations) in the trait data structure2000.

FIG. 23Bshows the example genomic network service update user interface2310, according to some example embodiments. In the example ofFIG. 23B, the user2300has scrolled down to a lower portion of the window2315. Below the network links2345and2350, existing content2360is displayed. The existing content2360can include root pages of studies or additional pages linked to the root pages that were previously published and existed in the trait data structure2000(e.g., the existing items2080). In some embodiments, the newly published studies conflict with studies previously stored in the trait data structure2000. For example, at a first point in time a study is published that asserts that consumption of red meat causes cancer, and then later at a second point in time, another study is published asserting that there is no relationship between consumption of red meat and cancer. As discussed above, the studies can be difficult for users (e.g., the user2300) to parse correctly through the client device108. To this end, a conflict spectrum visualization2365can be included in the window2315that gives context to potentially conflicting studies included in the existing content2360. In some embodiments, the root pages included in the trait data structure2000have metadata tags indicating whether they conflict with other studies. For example, the metadata tags can include a positive correlation metadata tag (e.g., a tag indicating that the root page asserts that consumption of red meat causes cancer), a negative correlation metadata tag (e.g., a tag indicating that the root page asserts no relation between consumption of red meat and cancer), and a neutral metadata tag (e.g., a tag indicating inconclusive results). The conflict spectrum visualization2365can be generated from the tags (e.g., tallying positive tags versus negative tags), and then included in the window2315to give visual context for newly published studies.

FIG. 24is a block diagram illustrating an example of a software architecture2402that may be installed on a machine, according to some example embodiments.FIG. 24is merely a non-limiting example of a software architecture, and it will be appreciated that many other architectures may be implemented to facilitate the functionality described herein. The software architecture2402may be executing on hardware such as a machine2500ofFIG. 25that includes, among other things, processors2510, memory2530, and I/O components2550. A representative hardware layer2404is illustrated and can represent, for example, the machine2500ofFIG. 25. The representative hardware layer2404comprises one or more processing units2406having associated executable instructions2408. The executable instructions2408represent the executable instructions of the software architecture2402, including implementation of the methods, modules, and so forth of the above figures. The hardware layer2404also includes memory or storage modules2410, which also have the executable instructions2408. The hardware layer2404may also comprise other hardware2412, which represents any other hardware of the hardware layer2404, such as the other hardware illustrated as part of the machine2500.

In the example architecture ofFIG. 24, the software architecture2402may be conceptualized as a stack of layers, where each layer provides particular functionality. For example, the software architecture2402may include layers such as an operating system2414, libraries2416, frameworks/middleware2418, applications2420, and a presentation layer2444. Operationally, the applications2420or other components within the layers may invoke API calls2424through the software stack and receive a response, returned values, and so forth (illustrated as messages2426) in response to the API calls2424. The layers illustrated are representative in nature, and not all software architectures have all layers. For example, some mobile or special-purpose operating systems may not provide a frameworks/middleware2418layer, while others may provide such a layer. Other software architectures may include additional or different layers.

The operating system2414may manage hardware resources and provide common services. The operating system2414may include, for example, a kernel2428, services2430, and drivers2432. The kernel2428may act as an abstraction layer between the hardware layer2404and the software layers. For example, the kernel2428may be responsible for memory management, processor management (e.g., scheduling), component management, networking, security settings, and so on. The services2430may provide other common services for the other software layers. The drivers2432may be responsible for controlling or interfacing with the underlying hardware layer2404. For instance, the drivers2432may include display drivers, camera drivers, Bluetooth® drivers, flash memory drivers, serial communication drivers (e.g., Universal Serial Bus (USB) drivers), Wi-Fi® drivers, audio drivers, power management drivers, and so forth depending on the hardware configuration.

The libraries2416may provide a common infrastructure that may be utilized by the applications2420and/or other components and/or layers. The libraries2416typically provide functionality that allows other software modules to perform tasks in an easier fashion than by interfacing directly with the underlying operating system2414functions (e.g., kernel2428, services2430, or drivers2432). The libraries2416may include system libraries2434(e.g., C standard library) that may provide functions such as memory allocation functions, string manipulation functions, mathematic functions, and the like. In addition, the libraries2416may include API libraries2436such as media libraries (e.g., libraries to support presentation and manipulation of various media formats such as MPEG4, H.264, MP3, AAC, AMR, JPG, PNG), graphics libraries (e.g., an OpenGI, framework that may be used to render 2D and 3D graphic content on a display), database libraries (e.g., SQLite that may provide various relational database functions), web libraries (e.g., WebKit that may provide web browsing functionality), and the like. The libraries2416may also include a wide variety of other libraries2438to provide many other APIs to the applications2420and other software components/modules.

The frameworks2418(also sometimes referred to as middleware) may provide a higher-level common infrastructure that may be utilized by the applications2420or other software components/modules. For example, the frameworks/middleware2418may provide various graphic user interface (GUI) functions, high-level resource management, high-level location services, and so forth. The frameworks/middleware2418may provide a broad spectrum of other APIs that may be utilized by the applications2420and/or other software components/modules, some of which may be specific to a particular operating system or platform.

The applications2420include built-in applications2440and/or third-party applications2442. Examples of representative built-in applications2440may include, but are not limited to, a home application, a contacts application, a browser application, a book reader application, a location application, a media application, a messaging application, or a gaming application.

The third-party applications2442may include any of the built-in applications2440, as well as a broad assortment of other applications. In a specific example, the third-party applications2442(e.g., an application developed using the Android™ or iOS™ software development kit (SDK) by an entity other than the vendor of the particular platform) may be mobile software running on a mobile operating system such as iOS™, Android™, Windows® Phone, or other mobile operating systems. In this example, the third-party applications2442may invoke the API calls2424provided by the mobile operating system such as the operating system2414to facilitate functionality described herein.

The applications2420may utilize built-in operating system functions (e.g., kernel2428, services2430, or drivers2432), libraries (e.g., system libraries2434, API libraries2436, and other libraries2438), or frameworks/middleware2418to create user interfaces for user interaction. Alternatively, or additionally, in some systems, interactions with a user may occur through a presentation layer, such as the presentation layer2444. In these systems, the application/module “logic” can be separated from the aspects of the application/module that interact with the user.

Some software architectures utilize virtual machines. In the example ofFIG. 24, this is illustrated by a virtual machine2448. A virtual machine creates a software environment where applications/modules can execute as if they were executing on a hardware machine (e.g., the machine2500ofFIG. 25). The virtual machine2448is hosted by a host operating system (e.g., the operating system2414) and typically, although not always, has a virtual machine monitor2446, which manages the operation of the virtual machine2448as well as the interface with the host operating system (e.g., the operating system2414). A software architecture executes within the virtual machine2448, such as an operating system2450, libraries2452, frameworks/middleware2454, applications2456, or a presentation layer2458. These layers of software architecture executing within the virtual machine2448can be the same as corresponding layers previously described or may be different.

FIG. 25illustrates a diagrammatic representation of a machine2500in the form of a computer system within which a set of instructions may be executed for causing the machine2500to perform any one or more of the methodologies discussed herein, according to an example embodiment. Specifically,FIG. 25shows a diagrammatic representation of the machine2500in the example form of a computer system, within which instructions2516(e.g., software, a program, an application, an applet, an app, or other executable code) cause the machine2500to perform any one or more of the methods discussed herein. For example, the instructions2516may cause the machine2500to execute the methodologies discussed above. The instructions2516transform the general, non-programmed machine2500into a particular machine2500programmed to carry out the described and illustrated functions in the manner described. In alternative embodiments, the machine2500operates as a standalone device or may be coupled (e.g., networked) to other machines. In a networked deployment, the machine2500may operate in the capacity of a server machine or a client machine in a server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine2500may comprise, but not be limited to, a server computer, a client computer, a personal computer (PC), a tablet computer, a laptop computer, a set-top box (STB), a personal digital assistant (PDA), an entertainment media system, a cellular telephone, a smart phone, a mobile device, a wearable device (e.g., a smart watch), a smart home device (e.g., a smart appliance), other smart devices, a web appliance, a network router, a network switch, a network bridge, or any machine capable of executing the instructions2516, sequentially or otherwise, that specify actions to be taken by the machine2500. Further, while only a single machine2500is illustrated, the term “machine” shall also be taken to include a collection of machines2500that individually or jointly execute the instructions2516to perform any one or more of the methodologies discussed herein.

The machine2500may include processors2510, memory2530, and I/O components2550, which may be configured to communicate with each other such as via a bus2502. In an example embodiment, the processors2510(e.g., a Central Processing Unit (CPU), a Reduced Instruction Set Computing (RISC) processor, a Complex Instruction Set Computing (CISC) processor, a Graphics Processing Unit (GPU), a Digital Signal Processor (DSP), an application-specific integrated circuit (ASIC), a Radio-Frequency Integrated Circuit (RFIC), another processor, or any suitable combination thereof) may include, for example, a processor2512and a processor2514that may execute the instructions2516. The term “processor” is intended to include multi-core processors that may comprise two or more independent processors (sometimes referred to as “cores”) that may execute instructions contemporaneously. AlthoughFIG. 25shows multiple processors2510, the machine2500may include a single processor with a single core, a single processor with multiple cores (e.g., a multi-core processor), multiple processors with a single core, multiple processors with multiple cores, or any combination thereof.

The memory2530may include a main memory2532, a static memory2534, and a storage unit2536comprising machine-readable medium2538, each accessible to the processors2510such as via the bus2502. The main memory2532, the static memory2534, and the storage unit2536store the instructions2516embodying any one or more of the methodologies or functions described herein. The instructions2516may also reside, completely or partially, within the main memory2532, within the static memory2534, within the storage unit2536, within at least one of the processors2510(e.g., within the processor's cache memory), or any suitable combination thereof, during execution thereof by the machine2500.

The I/O components2550may include a wide variety of components to receive input, provide output, produce output, transmit information, exchange information, capture measurements, and so on. The specific I/O components2550that are included in a particular machine will depend on the type of machine. For example, portable machines such as mobile phones will likely include a touch input device or other such input mechanisms, while a headless server machine will likely not include such a touch input device. It will be appreciated that the I/O components2550may include many other components that are not shown inFIG. 25. The I/O components2550are grouped according to functionality merely for simplifying the following discussion, and the grouping is in no way limiting. In various example embodiments, the I/O components2550may include output components2552and input components2554. The output components2552may include visual components (e.g., a display such as a plasma display panel (PDP), a light-emitting diode (LED) display, a liquid crystal display (LCD), a projector, or a cathode ray tube (CRT)), acoustic components (e.g., speakers), haptic components (e.g., a vibratory motor, resistance mechanisms), other signal generators, and so forth. The input components2554may include alphanumeric input components (e.g., a keyboard, a touchscreen configured to receive alphanumeric input, a photo-optical keyboard, or other alphanumeric input components), point-based input components (e.g., a mouse, a touchpad, a trackball, a joystick, a motion sensor, or another pointing instrument), tactile input components (e.g., a physical button, a touchscreen that provides location and/or force of touches or touch gestures, or other tactile input components), audio input components (e.g., a microphone), and the like.

Communication may be implemented using a wide variety of technologies. The I/O components2550may include communication components2564operable to couple the machine2500to a network2580or devices2570via a coupling2582and a coupling2572, respectively. For example, the communication components2564may include a network interface component or another suitable device to interface with the network2580. In further examples, the communication components2564may include wired communication components, wireless communication components, cellular communication components, Near Field Communication (NFC) components, Bluetooth® components (e.g., Bluetooth® Low Energy), Wi-Fi® components, and other communication components to provide communication via other modalities. The devices2570may be another machine or any of a wide variety of peripheral devices (e.g., a peripheral device coupled via a USB).

Moreover, the communication components2564may detect identifiers or include components operable to detect identifiers. For example, the communication components2564may include Radio Frequency Identification (RFID) tag reader components, NFC smart tag detection components, optical reader components (e.g., an optical sensor to detect one-dimensional bar codes such as Universal Product Code (UPC) bar code, multi-dimensional bar codes such as Quick Response (QR) code, Aztec code, Data Matrix, Dataglyph, PDF417, Ultra Code, UCC RSS-2D bar code, and other optical codes), or acoustic detection components (e.g., microphones to identify tagged audio signals). In addition, a variety of information may be derived via the communication components2564, such as location via Internet Protocol (IP) geolocation, location via Wi-Fi® signal triangulation, location via detecting an NFC beacon signal that may indicate a particular location, and so forth.

Executable Instructions and Machine-Storage Medium

The various memories (i.e.,2530,2532,2534, and/or memory of the processor(s)2510) and/or the storage unit2536may store one or more sets of instructions and data structures (e.g., software) embodying or utilized by any one or more of the methodologies or functions described herein. These instructions (e.g., the instructions2516), when executed by the processor(s)2510, cause various operations to implement the disclosed embodiments.

Transmission Medium