Policy-based genomic data sharing for Software as a Service tenants

Abstract

Policy-based genomic digital data sharing facilitates various sharing scenarios, including public access, tenant-to-tenant sharing, workgroup sharing, and access from external service providers. Genomic digital data can be published to the platform and controlled by access tokens generated based on access policies. These policies support conditions evaluated at runtime and effectively keep access control of information in the hands of the tenant. Sharing conditions can be easily specified to support various use cases, reducing the burden on administrators for excessive access control configuration.

Description

[0001] Cross-reference to related applications

[0002] This application claims the benefit of U.S. Provisional Application 63 / 045,736, filed June 29, 2020, which is incorporated herein by reference. Technical Field

[0003] This area generally involves sharing data among Software as a Service (SaaS) tenants. Background Technology

[0004] Research on genomic data can involve complex analyses conducted over time by parties with different expertise. Research typically begins with genomic data that may come from a variety of sources. This data can then be analyzed using a variety of techniques. Today's research projects may involve parties located around the world who share data and / or collaborate on data analysis. While progress has been made in this field and international standards for sharing genomic data have been established, significant challenges remain in sharing genomic data. Summary of the Invention

[0005] This summary is provided to introduce a series of concepts in a simplified form, which are further described in the detailed embodiments below. This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter.

[0006] In one implementation, a method includes: in a computing system comprising multiple tenants, the multiple tenants seeking access to a genomic digital data resource provided by one or more genomic data services in a software-as-a-service platform, the software-as-a-service platform encoding access to the genomic digital data resource via policy-based access control; receiving a policy-based access control definition for a first tenant among the tenants seeking access to the given genomic digital data resource; receiving a request for access to the given genomic digital data resource from a second tenant among the tenants seeking access to the given genomic digital data resource; and, for the second tenant among the tenants, granting access to the given genomic digital data resource based on the policy-based access control definition.

[0007] In another embodiment, a cloud-based multi-tenant system comprises: one or more processors; a memory coupled to the one or more processors; a policy store comprising policy-based access control definitions received for a first tenant and comprising a role identifier; a genomic digital data resource linked to the role identifier; wherein the memory comprises computer-executable instructions that cause the one or more processors to perform operations comprising: receiving a request to access the genomic digital data resource from a second tenant seeking access to the genomic digital data resource; and granting access to the genomic digital data resource to the second tenant according to the policy-based access control definitions evaluated at the time of the access request.

[0008] In another embodiment, one or more computer-readable media comprise: computer-executable instructions capable of causing a computing system to receive a publish request to provide a first tenant with access to genomic digital data, wherein access to the genomic digital data is controlled by a role identifier linked to a policy document, wherein the policy document comprises one or more conditions; computer-executable instructions capable of causing a computing system to receive a request from a second tenant to access the genomic digital data, wherein access to the genomic digital data is controlled by a role identifier linked to the policy document, wherein the request comprises one or more attributes; computer-executable instructions capable of causing the computing system to access the policy document in response to the request from the second tenant; and computer-executable instructions capable of causing the computing system to generate an access token based on the one or more attributes and the one or more conditions, wherein a role identifier is included in the access token in response to a determination that the one or more attributes satisfy the one or more conditions, and the access token authorizes access to the genomic digital data via the role identifier. BRIEF DESCRIPTION OF DRAWINGS

[0009] Figure 1 is a block diagram of an example system that implements policy-based sharing of genomic digital data.

[0010] Figure 2 is a flowchart of an example method that implements policy-based sharing of genomic digital data.

[0011] Figure 3 is a block diagram of an example system that includes a platform that implements policy-based sharing of genomic digital data via signed access tokens.

[0012] Figure 4 is a flowchart of an example method that implements policy-based sharing of genomic digital data via signed access tokens.

[0013] Figure 5is a block diagram of an exemplary system that generates signed access tokens based on access requests and policy documents.

[0014] Figure 6 is a flowchart of an exemplary method that generates signed access tokens based on access requests and policy documents.

[0015] Figure 7 is a visualization of supported scenarios.

[0016] Figure 8 is a block diagram of an exemplary policy document.

[0017] Figure 9 is a block diagram of an exemplary signed access token.

[0018] Figure 10 is a block diagram of an exemplary system that generates access tokens based on attributes of access requests and conditions of policy documents.

[0019] Figure 11 is a flowchart of an exemplary method that generates access tokens based on attributes of access requests and conditions of policy documents.

[0020] Figure 12 is a block diagram of a system that publishes genomic content for policy-based sharing.

[0021] Figure 13 is a flowchart of an exemplary method that publishes genomic content for policy-based sharing.

[0022] Figure 14 is a flowchart of an exemplary method that accesses published shared genomic content.

[0023] Figure 15 is a flowchart of an exemplary method that registers external service providers.

[0024] Figure 16 is a flowchart of an exemplary method that integrates external service providers into a policy-based sharing platform.

[0025] Figure 17 is a block diagram of an exemplary system that verifies signed access tokens.

[0026] Figure 18 is a block diagram showing integration of smart contracts into a policy-based sharing platform.

[0027] Figure 19 is a flowchart of an exemplary method that implements smart contracts in a policy-based sharing platform.

[0028] Figure 20 is a flowchart of an exemplary publishing use case.

[0029] Figure 21 This is a flowchart illustrating an example of an external service provider's usage instance involving registration.

[0030] Figure 22 This is a flowchart illustrating an example of an external service provider's use case involving integration.

[0031] Figure 23 This is a block diagram of an exemplary computing system in which the described implementation scheme can be carried out.

[0032] Figure 24 This is a block diagram of an exemplary cloud computing environment that can be used in conjunction with the techniques described herein. Detailed Implementation

[0033] Example 1 - Overview

[0034] The increasing availability of genomic data offers new opportunities for research and analysis. Today's sequencing platforms can generate various sequencing outputs, including whole-genome sequencing (WGS). Furthermore, various organizations such as the Global Alliance for Genomics & Health have established standards for sharing genomic data. However, in practice, today's genomic information ecosystem can sometimes appear fragmented. Data may be separated or segmented due to various considerations, including technical, security, legal, and financial reasons. And even when data is publicly available, it may not be fully integrated in a way that makes it immediately usable.

[0035] A significant obstacle is sharing information among parties. A completely open platform that allows all participants to share every piece of data from every other participant is neither realistic nor desirable. However, a policy-based approach to sharing genomic digital data among Software-as-a-Service tenants allows parties to share data in a controlled manner that encourages collaboration. Public data can be incorporated, and external service providers can also participate. Access control can be automated and easier to manage, without the need for lengthy and complex manual security management.

[0036] Therefore, cloud-based platforms can be used as virtual spaces where parties from diverse backgrounds and organizations can collaborate, sharing data, knowledge, tools, workflows, and applications to pool innovative insights and find new solutions.

[0037] Unrestricted by technology, data can be migrated to where it is needed and can foster a more collaborative ecosystem. Because these technologies are generally applicable to genomic digital data, they can be applied across a wide range of use cases involving the storage, retrieval, and analysis of genomic digital data.

[0038] Example 2 - Exemplary system implementing policy-based sharing of genomic digital data

[0039] Figure 1 This is a block diagram of an exemplary system 100 for implementing policy-based genomic digital data sharing. In this embodiment, multiple tenants 110A-N with associated user identifiers 120 access an application hosting platform instance 135 running on a data center 130. Platform instance 135 includes a platform authentication service 140, multiple hosted applications 150A-N, a management service 158, a policy repository 160 (e.g., with a policy document as described herein), and an authentication token 170. As described herein, some scenarios may involve trust documents (not shown) that can influence policy-based access to genomic digital data.

[0040] As part of the process, applications 150A-N can access one or more genomic data services 190A-N, which typically provide genomic digital data.

[0041] In practice, the complexity of the systems illustrated herein (such as system 100) can vary, with added functionality, more complex components, etc. For example, multiple data centers 130 may be implemented, and such data centers may implement multiple application hosting platform instances 135. Additional components may be included to achieve security, redundancy, load balancing, reporting design, etc.

[0042] The computing system can be networked via a wired or wireless network (including the Internet). Alternatively, the system can be connected via an intranet (e.g., in an enterprise environment, government environment, etc.).

[0043] System 100 and any other systems described herein may be implemented in conjunction with any of the hardware components described herein, such as computing systems (e.g., processing units, memory, etc.) described below. In any embodiment herein, genomic digital data, policy documents, authentication tokens, etc., may be stored in one or more computer-readable storage media or computer-readable storage devices. The techniques described herein are generalizable to the specific operating system or hardware and can be applied in any variety of environments to utilize the described features.

[0044] Example 3 - Exemplary method of implementing policy-based sharing of genomic digital data Figure 2 It is to implement strategy-based genomic digital data sharing and can be, for example, by Figure 1 A flowchart of an exemplary method 200 executed by a system (e.g., application hosting platform instance 135).

[0045] At position 210, a new tenant 210 joins. Therefore, a tenant identifier is assigned to this tenant, and the tenant is given the ability to share genomic digital data via the tenant identifier. In practice, this joining can be performed at any time before a request to publish data for sharing is received, and it does not necessarily have to be considered part of a publish / access scenario.

[0046] At point 220, the platform receives a request from a tenant to publish genomic digital data within the system, and this request includes a policy document controlling the sharing. In a computing system comprising multiple tenants, these tenants seek access to genomic digital data resources provided by one or more genomic data services within a software-as-a-service platform. This software-as-a-service platform coordinates access to the genomic digital data resources via policy-based access control, and may receive a policy-based access control definition (e.g., a policy document) for the first tenant among the tenants of a given genomic digital data resource. This definition may be received from the first tenant or another party (e.g., in an external service provider scenario).

[0047] At point 240, a request to access shared genomic digital data is received from another tenant. The request to access the given genomic digital data resource is received from the second tenant among those seeking access to the given genomic digital data resource.

[0048] At point 250, requests to access shared genomic digital data are permitted based on (e.g., according to) a policy document configured by the tenant (e.g., a tenant sharing genomic digital data). Access is permitted according to a policy-based access control definition. As described herein, a token may be provided in the access request. This token may be generated based on an relevant policy and can then be used to control access to the data (e.g., using a role identifier as described herein). Access to a given genomic digital data resource may be controlled by a role identifier linked to a policy-based access control definition.

[0049] In practice, a single party (e.g., operating the platform) may perform all the actions shown; however, it is also possible for one party to perform only some actions (e.g., joining), while another party performs other actions (e.g., granting permission). The division of tasks may also occur along domain lines (e.g., one party performs functions related to publishing, and another party performs functions related to granting access).

[0050] The actions shown can be interpreted from alternative perspectives while still implementing these techniques. For example, "receive request" can also be interpreted from the tenant's perspective as "send request".

[0051] Method 200 and any other methods described herein may be executed by computer-executable instructions (e.g., instructions that cause a computing system to perform the method) stored in one or more computer-readable media (e.g., storage media or other tangible media) or stored in one or more computer-readable storage devices. Such methods may be performed in software, firmware, hardware, or a combination thereof. Such methods may be performed at least in part by a computing system (e.g., one or more computing devices).

[0052] When these techniques are implemented in a computer-readable medium, they may include computer-executable instructions that enable a computing system to perform the corresponding method steps.

[0053] Example 4 - Exemplary genomic digital data

[0054] In any embodiment herein, genomic digital data can be a policy-based object of sharing. Such data can take the form of sequenced DNA, RNA, etc. (e.g., in the case of DNA, as the output of a sequencer, which is typically represented digitally as a chain of four nucleotides: adenine (A), cytosine (C), guanine (G), and thymine (T)). Nucleotides can be represented digitally in various ways and with different encodings, but are typically represented by equivalent strings of A', C', G', and T' for ease of description. Although DNA is given as an example, RNA sequencing can also be used. Similarly, the term "genome" encompasses information derived from the genome, exome, and transcriptome.

[0055] In practice, sequence information is accompanied by other useful information for research, including substantive data such as the origin of the DNA (e.g., the demographics of the subjects, their pathology, etc.). This may include disease and phenotypic information, and / or such information may be correlated with genomic digital data. Sequencing metadata may also be included (e.g., the machinery / instruments and techniques used to sequence the DNA, the date of sequencing completion, sequencing yield, quality metrics, pointers to sequencing run records, etc.). Other metadata may also be included, such as the name of the originator, legal restrictions, etc.

[0056] To facilitate sharing, data can be provided in a common format that allows for analytics and workflows to be used across tenants. Such a format can be proprietary or open to promote the open exchange of information in shared scenarios.

[0057] Policy-based sharing can be extended to other genomic data, such as executable workflow definitions related to genomic digital data. Therefore, tenants can access executable workflows for processing genomic digital data, as well as the underlying data itself, via the policy-based sharing technology described herein. Shared executable workflow definitions may originate from a single source (e.g., a tenant), while the underlying data may come from the same or different sources (e.g., the same tenant or different tenants). Such executable workflows may involve protocols already established for reliability, consistency of results, etc. Thus, for a specific research project, a given executable workflow can be shared across participants. Custom executable workflows can also be developed and shared by tenants.

[0058] Executable workflows can be performed by engines or services that interact with sequencing instruments (e.g., interpretation), greatly simplifying, automating, and increasing the reliability and reproducibility of the sequencing process. Error recovery and other features can be incorporated into such executable workflows. Workflows can be tailored to a variety of sequencing and related analysis tasks, such as demultiplexing, mapping and alignment, positional ordering, duplication labeling, variant detection, etc. Dedicated workflows can be designed for tumor-only or tumor-normal modes to detect somatic variants in tumor samples. Many other scenarios are possible.

[0059] Due to the lengthy computation times and massive amounts of data, such workflows can be used to provide agility, flexibility, and cost efficiency, enabling laboratories of all sizes and disciplines to better utilize their genomic data. The sharing technologies described in this article further facilitate the utilization of this data among tenants.

[0060] For convenience, shared genomic digital data is sometimes referred to as a “resource” or a “protected resource” to indicate that the data is a resource whose access is controlled through strategies as described in this article.

[0061] Genomic digital data can be provided by genomic data services. Such services may enforce access controls and collaborate with platforms such as those described herein to confirm and verify access tokens.

[0062] Example 5 - Exemplary software tenant

[0063] In any of the embodiments described herein, various software tenants may be supported. For convenience, software tenants are sometimes referred to as “tenants.” Such tenants typically take the form of enterprise tenants such as corporations, government entities, research institutions or groups, educational institutions or groups, user organizations, etc. By utilizing the techniques described herein, such tenants can greatly benefit from policy-based sharing.

[0064] Any given user on the platform can be assigned to a tenant. In a multi-tenant cloud system, users can share computing resources but have personalized, customizable user experiences and separately stored data. In practice, tenants tend to represent independent legal entities with separate agreements with the platform provider. Therefore, user identifiers are typically associated with a single tenant, and services are provided to users based on the agreement between the cloud provider and the tenant.

[0065] While tenants can share computing resources managed by the cloud service provider, the differentiating factors between tenants are that different tenants may have different subscriptions, different storage limits, and different access levels to the platform's genomic digital data and services. Various other customizations are also possible. Tenants are not necessarily application owners, as application owners can be cloud providers or third parties. However, some tenants may develop their own applications.

[0066] In cloud-based scenarios, a framework is transparently provided to users to leverage redundancy in functionality and processes across tenants. However, boundaries between tenants are enforced to prevent one tenant from accessing another's data. Each tenant's data is isolated and remains invisible to other tenants. This arrangement is often a fundamental characteristic of multi-tenant systems. However, while such isolation is generally desirable, for some data, allowing policy-based sharing between tenants, as described in this article, offers significant benefits.

[0067] Therefore, while the platform described herein may have the characteristics of a traditional cloud-based multi-tenant system, it may also allow controlled sharing between tenants (including proxy tenants as described herein).

[0068] Example 6 - Exemplary proxy tenant

[0069] In any of the examples in this document, proxy tenants can be implemented. A proxy tenant can register as a tenant and have a tenant identifier, but the tenant identifier is not used in the regular tenant functions, regardless of whether the entity it represents is an actual tenant of the platform. For example, in a public-shared scenario, a proxy tenant can be set up for public data, regardless of whether the data's source (e.g., owner) is actually involved (e.g., website, government agency, infrastructure, etc.), because the data is public. The proxy tenant has a tenant identifier, and digital genomic data can be published under that tenant identifier. In this way, the platform can support public-shared scenarios. In practice, all proxy tenants of data can also have actual tenant identifiers. Therefore, an organization can have multiple tenant identifiers, one identifying the source of the public genomic digital data, another identifying the research institution utilizing regular tenant functions, and so on.

[0070] Similarly, in external service provider scenarios, proxy tenants can be set up for external service providers. A tenant identifier can be assigned to the external service provider, which can be used to access data and upload data to the platform for sharing under that tenant identifier. In this way, the system can support external service providers. Likewise, external service providers can also have actual tenant identifiers, which are used when the external service provider is acting as a regular tenant.

[0071] Finally, platform administrators or other similar parties may operate as tenants or tenant representatives to provide any of the tenant-based functionalities described herein. This arrangement can be helpful when tenants do not wish to participate in the platform or when it is unavailable or impossible for them to do so.

[0072] Therefore, in any embodiment of this document, a tenant may be a proxy tenant, and the tenant identifier of such a tenant may be processed in accordance with the techniques described herein to enable policy-based sharing.

[0073] Example 7 - Exemplary roles

[0074] In any of the embodiments described herein, roles can be used to control access to shareable genomic digital data. As described herein, roles can be uniquely identified by role identifiers. Such role identifiers are created when a tenant wishes to publish a resource for sharing and links it to a policy document for a given resource.

[0075] Example 8 - Exemplary role bindings

[0076] To implement the techniques described herein, late binding of roles to users can be implemented. In a late binding scenario, a user identifier (or a tenant identifier of a user identifier) ​​can be bound to a role identifier at runtime rather than beforehand (e.g., when requesting access to a resource, when requesting a list of available resources, etc.). In this way, role assignment can be dynamic because if the policy changes, the role assignment can also change automatically. Therefore, roles can change over time without explicitly specifying a particular user. If the policy references such attributes, a user's membership in a tenant or workgroup may cause a change in role assignment. As described herein, binding can occur at the time of request and can be based on the requested user identifier or tenant identifier.

[0077] Similarly, policy-based sharing means that any change to the policy may lead to changes in sharing (e.g., role assignment). If such a factor changes, policies that also rely on other factors (e.g., protocol state, protocol level, subscription state, subscription level, etc.) may cause changes in role assignment. For example, if a tenant acquires a new subscription level, additional access from users of that tenant can be automatically permitted because roles can be assigned at runtime the next time a user of the tenant requests access.

[0078] Therefore, the late binding of roles and the dynamic nature of role assignment support a variety of flexible automated scenarios, avoiding the need for pre-assigning individual roles to specific users. This significantly reduces the resources required to manage the system while providing such rich functionality.

[0079] Additional roles can be provided at the application level (e.g., executed by the application); such roles can have early or late binding. For example, an application role identifier can specify a lab manager, supervisor, assistant, etc. The application role identifier itself can be used in conditional statements that control access to policy-based roles. In this case, in response to determining that an access request has attributes indicating that the role identifier satisfies the conditions specified in the policy document, the role is included in a signed access token with appropriate permissions (e.g., as specified for that role).

[0080] Example 9 - Exemplary permissions

[0081] In any of the embodiments herein, permissions for shared resources can be specified by specifying the service type, resource type, and permission type (e.g., “GDS.FILES.UPDATE”, “GSS.LIBRARYPOOLS.READ”, etc.).

[0082] Permission types may include management, archiving, creation, deletion, destruction, download, hiding, locking, reading, updating, writing, management, running, and granting permission. Resource types may include subscription, commit, sequencing run, library pool, library preparation toolset, analysis version, task version, task, run, and workflow.

[0083] Service types may include genomic data services, workflow execution services, etc.

[0084] Example 10 - Exemplary platform

[0085] In any embodiment herein, the provision of policy-based shared infrastructure is sometimes referred to as a “platform.” Such a platform can be integrated into a cloud-based multi-tenant platform that provides tenants with access to multiple applications. As described herein, such a platform can serve as a virtual venue where tenants can collaborate via the sharing features described herein.

[0086] The platform can be implemented as a Software as a Service (SaaS) platform that uses policy-based access control technology described herein to coordinate access to genomic digital data resources.

[0087] The various components of a function may be described as residing within or outside the platform, but can be implemented in either manner. For example, some functions may be delegated to other service providers or brought into the platform as needed. In some cases, a function may be described as being within an authentication service platform, which may be separate from or integrated into the overall cloud-based multitenant platform.

[0088] Example 11 - Exemplary system with platform implementing policy-based sharing

[0089] Figure 3 This is a block diagram of an exemplary system 300 including platform 350, which implements policy-based genomic digital data sharing via a signed access token 372.

[0090] Although the application is not shown, in practice, the actual sharing function can be invoked by an application that runs on behalf of the tenant and requests access to the genomic digital data 397 via platform 350 and supporting software.

[0091] In this embodiment, the tenant 310A controls access to the genomic digital data 397. This control is achieved through a configuration policy document 360 (e.g., via a management user interface). Configuration may include creating a custom role identifier 374 for inclusion in the policy document 360. This configuration may be included as part of the publishing process when the tenant 310A wishes to publish the data 397 for sharing. Although not shown, publishing may also include generating a signed permission token as described herein.

[0092] Subsequently, when tenant 310B wishes to access data 397, it can do so by sending a request 320 to platform 350. Policy document 360 controls the generation of signed access token 372 as described herein (e.g., the signed access token may also include a role identifier 374).

[0093] Tenant 310B can then send an access token 372 with a role identifier 374 to the Genome Digital Data Service, which uses the token 372 to provide access to the Genome Digital Data 397.

[0094] Example 12 - Exemplary method of implementing policy-based sharing

[0095] Figure 4 It is a policy-based sharing of genomic digital data implemented via signed access tokens and can be, for example, by systems such as Figure 3A flowchart of an exemplary method 400 implemented by the system shown (e.g., platform 350).

[0096] In any embodiment of this document, in response to receiving an access request, a role identifier specified in a policy-based access control definition (e.g., a policy document) may be provided for the access request. This role identifier may then be included in the signed access token.

[0097] In this embodiment, at 410, the configuration of the policy with role identifiers is received from the controlling (e.g., owner or delegate) tenant.

[0098] At position 420, an access request for data controlled by this policy configuration is received from another tenant. As described herein, such a request may involve a request for a token.

[0099] At 430, the request is permitted based on a configured policy (e.g., a policy document controlling the tenant configuration). For example, at 440, a signed access token (e.g., with a role identifier) ​​may be provided based on the policy. At 450, the access request may be permitted based on the signed access token (e.g., based on the existence of an appropriate scope of the role identifier).

[0100] Example 13 - Exemplary self-owned tenant

[0101] In any embodiment herein, the term "owner-tenant" can be used to express that policy-based sharing is essentially tenant-to-tenant sharing. Owner-tenants can grant access to genomic digital data they already have access to. By publishing the data and configuring a policy document, other tenants can then access the owner-tenant's data.

[0102] In practice, owned tenants can delegate shared management to another tenant, who can then mimic the owned tenant for shared purposes. Therefore, owned tenants are sometimes referred to as "primary tenants".

[0103] Example 14 - Exemplary access request

[0104] In any embodiment herein, the access request may take various forms. For example, the access request may specify genomic digital data that is desired to be shared (e.g., using an identifier). Alternatively, a general request may be sent, and a list of available resources and associated identifiers may be provided for selection. The access request can then be completed by providing an identifier for the specific resource desired.

[0105] In practice, the access request can be provided through communication between the application and the platform that provides policy-based sharing services.

[0106] A signed access token can be received in response to the request, and this token is used to actually control access to the protected resource.

[0107] In a session-based system, an access request can be sent at the start of a session (e.g., user authentication), and an access token can be generated based on the user's identity. The application that originates from the session can then access the resources indicated by the role in the access token.

[0108] Example 15 - Exemplary invitation

[0109] In any embodiment herein, an invitation process can be used to invite tenants to share. For example, newly joined tenants may receive certain invitations by default. Other tenants may receive invitations when registering for a specific application or service. For example, a subscription model for an application may provide access to the application (e.g., and any associated public data shared herein) upon subscribing to the application. Other tenants may receive invitations as part of a policy document.

[0110] In practice, invitations can be controlled through policy documents or by indicating when to initiate sharing of other resources.

[0111] The invitation process may include legal compliance, identity verification, key exchange, and trust delegation.

[0112] Example 16 - Exemplary system for generating signed access tokens

[0113] Figure 5 This is a block diagram of an exemplary system 500 that generates a signed access token 572 based on an access request 520 and a policy document 560.

[0114] In this embodiment, a given tenant's user identifier 505 is accessing application 510, which requests access to basic genomic digital data 597.

[0115] Access request 520 may include multiple attributes, and in this embodiment includes user identity set 530, which includes workgroup identifier 535, tenant identifier 537 and application identifier 540.

[0116] (For example, Figure 1 Authentication service 140 or Figure 3 The platform authentication service token generator of platform 350 receives access request 520 as input and generates a signed access token 572 based on policy document 560. In this embodiment, user identity set 530 and application identifier 540 support access, so token 572 includes role identifier 574 and tenant identifier 576 of the tenant in question (e.g., whose associated user is a user).

[0117] When a signed access token 572 is available, the genomic data service 590 can verify the token and provide access based on the presence of a role identifier 574, which can also be used in the access control list 595 of the genomic data service 590 to provide access to the underlying data 597.

[0118] Further security can be provided via permission tokens as described in this article.

[0119] Example 17 - Exemplary method for generating signed access tokens

[0120] Figure 6 It generates a signed access token and can be generated by, for example, a system such as Figure 5 A flowchart of an exemplary method 600 implemented by the system shown (e.g., token generator 550).

[0121] At position 610, an access request is received from the user identity set. In practice, the application being used by a user with the user identity set can actually send the request on behalf of the user's identity.

[0122] At point 620, a role identifier is included in the signed access token based on the policy document associated with the protected resource and one or more attributes of the access request. For example, in a scenario where all tenants are granted access to a particular application, a role identifier may be included in response to determining that the access request originates from an instance of that application. If all tenants with that application are granted such access, user identity may not play a role in that decision. However, in a tenant-to-tenant sharing scenario, tenant identity can be a controlling factor (e.g., the requesting tenant's tenant identifier must match conditions specified in the policy document). Depending on the conditions specified in the policy document, the requested workgroup identifier may or may not be a controlling factor.

[0123] At position 640, a signed access token with a role identifier is sent to the genome data service.

[0124] Access to genomic digital data can then be granted based on role identifiers.

[0125] Example 18 - Exemplary application

[0126] like Figure 5 As shown, application 510 may send access requests on behalf of user identifier 505. In any embodiment herein, although the request may be described as originating from a tenant or user identifier, in practice, the application may act on behalf of such a tenant or user identifier. The application instance may be associated with an authenticated user identifier and / or tenant identifier used for security purposes (e.g., authentication requests, determining a tenant identifier, determining a workgroup identifier, etc.).

[0127] Such applications can take many forms and can be used for the acquisition, management, and analysis of genomic digital data, as described in this article.

[0128] Example 19 - Exemplary support scenarios

[0129] Figure 7 It is a visualization 700 that supports scenario 710, which can be implemented via the technology described herein.

[0130] Public access sharing 720 can be implemented as described herein by publishing publicly available or desired publicly available genomic digital data under a tenant identifier used to configure a policy document stating the availability of that data (e.g., for all users, all users of a given application, or some other criterion).

[0131] Examples of public access sharing can be implemented relative to an application. Thus, for example, any tenant subscribing to a particular application may be permitted access to a collection of public data in a format compatible with that application. In this case, a policy document could specify that requests from that application (e.g., "application:Olympia") are permitted for access to shared public data for all tenants (e.g., "tid:*").

[0132] Tenant-to-tenant sharing 730 can be implemented as described herein by publishing genomic digital data under a tenant identifier configured with a policy document that specifies conditions for controlling the sharing (e.g., which other tenants can access the data). Although an invitation process may be involved, other tenants do not need to configure this role identifier, as the controlling tenant can do so.

[0133] Workgroup-based sharing 740 can be implemented as described herein by publishing genomic digital data under a tenant identifier configured with a policy document that specifies the conditions for controlling the sharing (e.g., which one or more workgroups can access the data). Although an invitation process may be involved, workgroup members do not need to configure this role identifier, as the controlling tenant can do so. Workgroups can be intra-tenant or inter-tenant (e.g., across multiple tenants).

[0134] Sharing to / from external service providers can also be implemented, as described herein, by creating a special tenant identifier for the external service provider, even if they do not act as tenants. In this way, the external service provider can access the genomic digital data on the platform, perform analysis on the data, and publish the results back to the platform for access by tenants (e.g., those requesting the external service provider to perform analysis).

[0135] Other scenarios are possible because policy documents can include a rich set of conditions that allow sharing. Methods for evaluating policy documents at execution time can be used to avoid large-scale reconfiguration of individual user roles by tenant administrators.

[0136] Example 20 - Exemplary workgroups

[0137] In any embodiment herein, any number of users can be assigned to members of a workgroup identified by a workgroup identifier within the platform. Such users can be from the same tenant or across different tenants. Membership in the workgroup can be controlled by an administrator or a programmatic process.

[0138] Example 21 - Exemplary token signing

[0139] In any embodiment herein, the access or permission token may be digitally signed by the controlling tenant for authentication. In practice, a public-private key encryption method may be used, wherein the token is signed with the tenant's private key and authenticated with the tenant's public key.

[0140] In practice, the platform administrator's or representative's key can be used in place of the tenant's key to simplify management. Any key that is trusted and verifiable by the platform can be used to establish a trust relationship that is enforced to prevent unauthorized sharing between tenants.

[0141] Example 22 - Exemplary policy documents

[0142] In any of the embodiments described herein, a policy document can be used to control sharing. Such a policy document can therefore be used as a policy-based access control definition. As described herein, the policy-based access control definition can be evaluated upon receiving an access request.

[0143] Figure 8 This is a block diagram of an exemplary policy document 860 that may be used in any embodiment herein. In practice, policy document 860 is configured (e.g., created, read, updated, or deleted) by tenants of resources (e.g., genomic digital data) associated with policy document 860 in a control platform. For example, a management user interface may be provided for access by an administrator user of the tenant, or the configuration may be done programmatically if desired.

[0144] As described herein, policy document 860 may filter access requests based on application identifiers or names, identities (e.g., tenant identifiers, workgroup identifiers, etc.). Although not shown, policy document 860 may be linked (e.g., mapped) to role identifiers (e.g., controlled by configured tenants), and policy document 860 thus controls access by acting as a gatekeeper for role identifiers, which can ultimately be used to authorize access to protected shareable resources.

[0145] Filtering can be performed using various formats. In this embodiment, the policy document 860 may include metadata 861 (e.g., date, version, etc.) and one or more statements 862. These statements may take the form of effects, tenant identity parameters 863, and zero or more conditions 864. The effect may specify that it takes effect if the identity parameter 863 and condition 864 (if any) are met. This effect may be to allow sharing (e.g., "allow") or allow a specific type of sharing (e.g., read-only, read-write, etc.), or grant the permissions described herein; however, the type of sharing may alternatively be implemented by creating different role identifiers with different access levels.

[0146] In practice, identity 863 is listed separately to emphasize that tenant identity parameters are typically specified as part of policy document 860 and effectively used as conditions. For example, a specific tenant, a list of tenants, or a wildcard can be listed as a tenant identity parameter. If a request comes from a tenant identifier that satisfies a tenant identity parameter, the parameter is considered satisfied, and if any other condition 864 is also met, these statements will be executed.

[0147] As described herein, given condition 864 may include filter parameters such as application identifier, workgroup identifier, application role identifier, etc. Requests with attributes that satisfy the condition trigger the execution of statements (e.g., enable access). Therefore, access to underlying roles can be filtered based on such attributes.

[0148] If the policy document is satisfied, the link's role identifier is included in the generated access token, as described in this document.

[0149] Additional features or configurations can be incorporated into policy document 860 as needed to extend shared functionality. For example, policy document 860 can incorporate or reference trusted external resources such as the smart contracts described herein.

[0150] Example 23 - Exemplary signed access tokens

[0151] In any of the embodiments herein, a shared access token may be generated based on a policy document and an incoming access request to control access to resources linked to the policy document (e.g., via role identifiers).

[0152] Figure 9 This is a block diagram of an exemplary signed access token 972 that can be used in any embodiment herein. In practice, an actual token 972 may take different forms, having more or fewer fields.

[0153] Subject 974 can be a system user identifier.

[0154] Publisher 976 can indicate which instance of the platform's authentication system issued the token. Alternatively, the publisher can be the controlling tenant.

[0155] Tenant identifier 978 can indicate the tenant identifier of a user (e.g., a user associated with an application that requests resources).

[0156] Members can be encoded into the access token 972 based on user roles and permissions, and whether the user meets policy criteria. During access token generation, the user identifier that meets the policy criteria automatically retrieves the associated role identifier as a member according to the policy set when access was granted. 980 may include a list of members that the user has access to. Members may be indicated by role identifier 982 and / or workgroup identifier 984. A permission index (or all as "*") may be included. For example, a user may have membership in both a role and a workgroup simultaneously.

[0157] Access control list 990 may include tenant identifiers and user identifiers, as well as the granted permissions to the associated resources. The access control list in token 972 may be included for efficiency purposes (e.g., to eliminate the need to check a separate access control list), or it may be used as a review of an already in place access control list (e.g., an access control list that has been sent to the genomic data service as part of an authorization token).

[0158] Permission type 992 can indicate the permission type or the authentication flow regarding how a user obtains token 972.

[0159] Audience 994 can determine which cloud provider's service the user is trying to access.

[0160] Service 996 indicates that the user is using the application or service to generate token 972.

[0161] Scope 998 may include a list of granted permissions (e.g., identifiers indicating the granted access types by specifying service type, resource type, and permission type (e.g., “GDS.FILES.UPDATE”, “GSS.LIBRARYPOOLS.READ”, etc.)).

[0162] In practice, the Signed Access Token 972 can be implemented as a JSON network token or other format that supports the storage of relevant fields. This token can be signed with the signer's private key, allowing authentication via the signer's public key.

[0163] Example 24 - Exemplary access token generation system

[0164] Figure 10 This is a block diagram of an exemplary system 1000 that generates an access token 1072 based on the attributes of access request 1020 and the conditions of policy document 1060.

[0165] In this embodiment, the access request 1020 may include a set of one or more attribute name 1040A-N-attribute value 1042A-N pairs. For example, the attribute may indicate the tenant, workgroup, application associated with the requesting user identifier, etc.

[0166] The strategy document 1060 may include a role identifier 1074, which may not be explicitly stored in the document 1060 but may be linked to the document (e.g., in a mapping between role identifiers and the strategy document). The strategy document 1060 may include multiple conditions 1064A-N, including corresponding filter attribute 1064A-filter parameter 1066A pairs. The filter attribute 1064A may specify the attribute by name or identifier, and the filter parameter 1066A may specify parameters indicating which attribute values ​​are eligible for the assignment of the role identifier 1074. In practice, the parameter 1066A may take the form of a single value, a list, a wildcard, etc.

[0167] Access token generator 1050 can match policy parameters with attributes (e.g., those of the incoming request). It can also include external conditions (e.g., conditions that are not part of access request 1020).

[0168] If access request 1020 is eligible for role assignment as indicated by conditions 1064A-N, then role identifier 1074 may be included in access token 1072 along with (for example, the tenant identifier of the requesting user).

[0169] The token 1072 can be signed using a private key (for example, controlling the tenant or cloud service provider). This signing can be achieved using conventional or other public-private key encryption methods and can be a separate function from the token generator 1050. Once signed, the signer's public key can be used to authenticate the token 1072.

[0170] Example 25 - Exemplary access token generation method

[0171] Figure 11 It generates access tokens based on the attributes of the access request and the conditions in the policy document, and can be generated, for example, by... Figure 10 A flowchart of an example method 1100 implemented by a system 1000 (e.g., an access token generator 1050 or other access token generation system described herein).

[0172] At 1110, a request for access to shared genomic digital data is received, and the request includes one or more attributes. Such attributes may take the form of attribute name-attribute value pairs, but the attribute names may be implied (e.g., based on their position within the request).

[0173] At 1120, access the policy document for sharing genomic digital data, and the policy has one or more conditions.

[0174] At 1140, an access token is generated based on one or more attributes of the request and one or more conditions of the policy. For example, a role identifier may be included if the attribute indicates that the request meets the conditions of the policy. External attributes may also be included to influence token generation (e.g., whether the requester's tenant has an increased subscription level, etc.).

[0175] As described in this article, the obtained tokens can be signed.

[0176] Example 26 - Exemplary genomic digital data publication system

[0177] Figure 12 This is a block diagram of a system 1200 that publishes basic data (e.g., digital genomic data) 1297 for policy-based sharing. In practice, system 1200 may be incorporated into any of the policy-based sharing embodiments described herein and invoked to configure (e.g., set) sharing.

[0178] In this embodiment, control tenant 1210 accesses workgroup administrator console 1220 to provide access to shared underlying data 1297 provided by genomic data service 1290.

[0179] Access control list 1292 can be created to enforce restrictions on data 1297. Access control list 1292 may include an entry indicating the control tenant identifier 1234, a role identifier 1236 created for a given policy-based sharing scenario, and granted permissions 1278 (e.g., indicating resource type, access type, etc.).

[0180] Tenant 1210 generates a policy document 1260, which is included in the policy repository 1255 and linked (e.g., mapped) with tenant 1210’s tenant identifier, role identifier 1236 and underlying data 1297.

[0181] In this embodiment, policy document 1260 includes metadata about the version and statements allowing access to all tenants (e.g., "TID:*") accessing data via the application "Olympia". A signed permission token 1230 is created, which includes one or more access control lists determined by the publishing scenario. In this way, the access control lists can be sent to genomic data service 1290, where they are stored for future reference (e.g., granting permissions based on a request associated with role ID 1236). In this embodiment, a tenant identifier 1234 controlling the tenant and a role identifier 1236 created for the policy-based sharing scenario are included.

[0182] The scenario shown is sometimes referred to as “publishing” data (e.g., data 1297) because tenant 1210 has made the data available to eligible people (e.g., because those requests meet the conditions in policy 1260).

[0183] Example 27 - Exemplary genomic digital data publication method

[0184] Figure 13 It involves publishing genome content for policy-based sharing and, for example, by... Figure 12 A flowchart of an exemplary method 1300 implemented by a system 1200 (e.g., a workgroup administrator console 1220 or other part of a platform that supports policy-based sharing as described herein). As described herein, method 1300 may be driven by tenant-permitted access (e.g., a workgroup administrator).

[0185] At 1320, create a custom role identifier (e.g., along with a policy document linked to the role identifier). This role identifier can be unique within the platform and is assigned in response to a release request.

[0186] At 1340, a signed permission token is created using an access control list. This permission token may be associated with (e.g., linked to) a resource identifier that identifies the genomic content as described herein.

[0187] At point 1360, use a permission token to publish the content to the genome data service. For example, if the data does not already exist, it can be uploaded to the genome data service. The permission token can be verified to control access to protected resources.

[0188] Example 28 - Exemplary genomic digital data access method

[0189] Figure 14 This is a flowchart of an exemplary method 1400 for accessing published shared genomic content, which can be implemented, for example, by any system that supports policy-based sharing as described herein. This method is typically driven by an enterprise user identifier accessing the resource.

[0190] At 1420, an access request is received (e.g., received by the platform from the access user identifier of a given access tenant).

[0191] At 1440, a signed access token is generated as described herein (e.g., based on a policy).

[0192] At point 1460, access to genomic digital data resources is achieved using a signed access token. For example, a request can be sent to a genomic data service, which then responds with the data.

[0193] Example 29 - Exemplary external service provider registration method

[0194] Figure 15 This is a flowchart of an exemplary method 1500 for registering external service providers and which can be implemented, for example, by any system that supports policy-based sharing as described herein. This method 1500 is typically driven by managing user identifiers or processes. As described herein, it can support a variety of external service provider scenarios.

[0195] At point 1520, (e.g., by the platform) registration from external service providers is received. This registration may include the scope and permissions of access and can be performed by the managing user.

[0196] At 1540, registration of external service providers as proxy tenants is accepted. A tenant identifier can be used for this proxy tenant, even if the external service provider may not be acting as a tenant or participating as a full tenant of the platform.

[0197] At point 1560, policy-based access control is created (e.g., enabling tenant-to-tenant sharing via a role created under a proxy tenant of an external service provider). Policies can be associated with roles. In practice, data is assumed to be owned by the external service provider (via a proxy tenant identifier) ​​and shared with access tenants via policy-based sharing as described herein.

[0198] The following Figure 21 More detailed usage examples are described in the text.

[0199] Example 30 - Exemplary external service provider integration method

[0200] Figure 16 This is a flowchart of an exemplary method 1600 for integrating external service providers into a policy-based sharing platform, and which can be implemented, for example, by any system that supports policy-based sharing as described herein. This method 1600 is typically driven by an access user identifier (e.g., from another tenant) or a process.

[0201] At point 1620, initiate a workflow for communicating with an external service provider. This workflow can be initiated to perform tasks associated with an external service provider. For example, a tenant may have submitted a physical biological sample and wish to receive digital genomic data results from the analysis of that sample; a tenant may have generated genomic digital data (such as sequencing results) and wish for the results to be interpreted by an external service provider.

[0202] At point 1640, an authorization token is generated for the external service provider (e.g., for a specific shared scenario). In practice, the workflow execution service executing the workflow can request the generation of an authorization token.

[0203] At 1660, an external service provider is invoked using an authorization token, which is verified (e.g., using an administrative public key).

[0204] At point 1660, results are received from external service providers (e.g., biological sample analysis, data analysis, etc.) and accepted into the genomic data service (e.g., where they are accessible to users of the tenant who initiated the workflow involving the external service provider). For example, the external service provider uploads the results to the genomic data service using a signed access token provided by the requesting tenant or on behalf of the requesting tenant.

[0205] The following Figure 22 More detailed use cases and sample strategies are described in the document.

[0206] Example 31 - Exemplary external service provider

[0207] In any embodiment herein, the external service provider can be a service provider that offers genomic data services to tenants of the system. Therefore, the tenant receiving the policy-based access control definition can be a proxy tenant, representing the external service provider for whom policy-based sharing is implemented. Because this external service provider operates outside the system (e.g., not as a tenant of the system), a proxy tenant identifier can be set for use by the external service provider, and the external service provider can register with the platform as associated with the proxy tenant identifier. As described herein, the external service provider can then utilize the policy-based tenant-to-tenant sharing technology described herein.

[0208] Such service providers can perform useful services, such as analyzing physical biological samples and uploading the results (e.g., digital genomic data), analyzing genomic data (e.g., using mathematical processes, machine learning, etc.), etc.

[0209] From a user's perspective, external service providers can appear as third-party applications, offering their services to users. This approach enables a rich research ecosystem where third-party applications can connect to the platform, freeing it from being limited to applications provided solely by the platform configurer or other tenants.

[0210] Example 32 - Exemplary token validation

[0211] Figure 17This is a block diagram of an exemplary system 1700, where authentication (e.g., certification) can be implemented as a signed access token for token authentication in any of the embodiments herein. In this embodiment, the signed access token 1772 (having a role identifier 1774 and a tenant identifier 1776) is signed with the private key of the controlling tenant 1710. In practice, the controlling tenant's private key may be managed by the tenant or an administrator of the cloud service provider (e.g., a platform configurer).

[0212] The authenticator 1780 can accept the public key of the controlling tenant 1710 and the signature token 1772, and output the authentication result 1790 (e.g., whether the token 1772 was indeed signed by the private key of the controlling tenant 1710). The authenticator 1780 can perform the verification of the token 1772 using conventional public-private key encryption algorithms (e.g., including hashing).

[0213] Following verification, further processing can be performed to determine whether permissions are available for a given resource (e.g., based on membership, such as role identifiers, workgroup identifiers, etc.). In response to determining that membership satisfies specified conditions (e.g., satisfying an access control list), the associated permissions (e.g., in the access control list) are granted to the requester associated with the token.

[0214] Although a signature access token 1772 is shown, system 1700 can also be used with the signature permission token described herein.

[0215] Example 33 - Exemplary genomic data implementation

[0216] In any of the embodiments herein, genomic data may be in the form of a genomic file type. Such file types can be associated with different types of genomic data, distinguishing between data obtained during genome sequencing (e.g., raw data from sequencing instruments, assembled genomes, etc.), auxiliary data during assembly (e.g., a reference genome), and data indicating the results of comparative genomic analysis. Comparative genomic analysis may include comparisons between genomes (e.g., file types indicating single nucleotide polymorphisms, insertions, deletions, structural variations, and copy number variations within the genome compared to a reference genome).

[0217] An example of this file type is the VCF (SNP) file type. VCF stands for "Variation Detection Format." It is a standardized text file format used to represent SNP, INDEL, SV, and CNV variant detections. SNPs (Single Nucleotide Polymorphisms) are the most common type of genetic variation between human genomes. Each SNP represents a difference in a single DNA structural unit (e.g., a nucleotide). In practice, this is the widely used VCF.

[0218] Another example of a file type is the VCF (INDEL) file type. INDEL is a molecular biology term referring to insertions or deletions in DNA. The number of INDELs in the human genome is second only to the number of SNPs. INDELs can play a crucial role in genetics.

[0219] Another example is the VCF(SV) file type. SV (or structural variant) is a large DNA sequence that has been inserted, reversed, deleted, or copied within the genome.

[0220] Another example is the VCF (CNV) file type. CNV (or copy number variation) refers to the variation in the copy number of a specific gene from one individual to another. Some cancers are thought to be associated with elevated copy numbers of specific genes.

[0221] Another example is the BAM file type. Binary Alignment Maps (BAMs) can be the full, raw data of a genome sequence; this type can include a lossless, compressed binary representation of the sequence alignment map. BAM files tend to be approximately 90-100 megabytes in size. BAM files are generated by aligning a FASQ file to a reference genome. A BAM file (.bam) is a binary version of a SAM file. A SAM file (.sam) is a tab-delimited text file containing sequence alignment data.

[0222] Another example is the FASTQ file type. FASTQ files contain billions of entries and are approximately 90-100 megabytes in size, making them too large to open in a regular text editor. FASTQ files can be based on raw data.

[0223] Another example is the quality control metric file type (e.g., a report). The quality of the underlying data can be checked before running any alignments or assemblies. Quality can be checked within the sequencing program. Quality control analyses can test many different metrics and generate a comprehensive report. This report may include a simple categorization (e.g., red, yellow, green) to indicate whether the result is bad, moderate, or good.

[0224] Example 34 - Exemplary permissions for specific use cases

[0225] In any of the embodiments described herein, specific permissions for the genome context can be implemented. For example, the granularity of permissions can be extended to file type in the policy statement. Thus, the policy can specify that different tenants, workgroups, users, or application roles may have different permissions for different genome file types or different categories of genome file types (e.g., raw sequencing data, assembled genomes, reference genomes, comparative genome analyses, etc.).

[0226] Specialized, so-called "background" permissions allow applications or other infrastructure to use resources (e.g., file types) without granting read access (e.g., therefore, direct read access is not permitted). For example, granting background permissions to a reference genome allows the reference genome to be used to assemble raw data, determine single nucleotide polymorphisms, or perform other comparative genomic analyses, without granting read access to the reference genome itself.

[0227] Additionally, dedicated permissions can be assigned to executable workflows. For example, "Advanced Run Only" permission allows advanced visibility of the workflow (e.g., steps, step progress, error messages, etc.) without revealing detailed workflow information (e.g., underlying interpreted code) or allowing modification of the workflow. Therefore, workflows can be shared among tenants without exposing all the less important technical details.

[0228] Example 35 - Exemplary application implementation

[0229] In any of the embodiments described herein, the application can be used to facilitate genomics use cases, such as clinical genomics. For example, a cloud-based in vitro diagnostic solution for oncology can be built into an application that supports sample registration, wet laboratory protocols (e.g., extraction, library preparation, indexing / pooling), sequencing, demultiplexing, sequencing quality control, and then secondary analysis, ultimately generating a report. Secondary analysis may include comparative genomic analysis, such as the detection of single nucleotide variants.

[0230] This application can coordinate various services and unify the management of genomic data to achieve efficient and accurate collection and analysis. For example, genomic laboratory services, workflow services, event notification services, task services, and genomic data repositories can work collaboratively under the orchestration of applications running in the shared environment described herein.

[0231] Therefore, different participants working as tenants or external service providers can use the policy-based genomic data sharing technology described in this article to collaborate and share information.

[0232] Example 36 - Exemplary smart contract integration

[0233] Figure 18 This is a block diagram illustrating the integration of smart contract 1865 into a policy-based sharing platform. The smart contract can be implemented to extend policy document functionality in any of the embodiments herein. Policies can reference contracts, allowing anyone who satisfies the contract to access data via the policy; conversely, default or non-satisfaction with the contract means that a party cannot access the data via the policy. Parties can be designated as tenants, workgroups, etc.

[0234] In this embodiment, the platform authentication service token generator 1850 queries strategy 1860 to determine how to generate a signed access token 1872 with a role identifier 1874 and a tenant identifier 1876. As described herein, the generator 1850 may also query one or more attributes of an incoming request (e.g., tenant identifier, application identifier, etc.).

[0235] As shown in the figure, policy document 1860 may include or index smart contract 1865. Smart contract 1865 itself may index blockchain service 1897 which stores protocols for one or more tenants 1810A-N. Such protocols may exist between tenants, between tenants and cloud service providers, between tenants and third parties, or some combination thereof. Such blockchain service may utilize blockchain technology, such as consensus-based immutable records of protocols (e.g., protocol existence, protocol level, service level, etc.), and be built on blockchain infrastructure from any of various providers or technologies (e.g., Ethereum-based functionality, etc.).

[0236] Trust relationships between platforms and services, and between tenants, can be established via trust documents, which can facilitate the automatic evolution of policy documents 1860 based on the protocols indicated by service 1897.

[0237] In this way, tenants who meet the contract terms can access the data specified in the relevant policies. Therefore, automated contract management is provided, facilitating immediate access to the contract-defined data upon fulfillment of contract terms (such as payments, subscriptions, or other terms).

[0238] Permission tokens can be generated based on the completion of a contract, and access tokens can be generated upon request for access according to an associated policy.

[0239] As another feature, access to data can be logged for use in subsequent auditing functions. Such logs can indicate the date and time of access, the identifier of the requesting party, the identifier of the granting party, and the policy that allowed access, and can themselves be annotated for compliance or legal reasons (e.g., "the agreement between Party X and Party Y dated December 15, 2017").

[0240] Example 37 - Exemplary trust documents

[0241] In any of the embodiments described herein, a policy-based sharing platform may record trust relationships between tenants as a trust document. For example, a trust document may store a tenant’s consent agreement reflecting that trust has been established with another tenant (e.g., by storing the source tenant, target tenant, consent agreement date, and consent metadata).

[0242] This trust document can be enforced as a prerequisite for sharing data with tenants. For example, in this scenario, the policy will only take effect if the trust document supports it.

[0243] Example 38 - Exemplary smart contract method

[0244] Figure 19 This is a flowchart of an exemplary method 1900 for implementing smart contracts in a policy-based sharing platform, which can be implemented to extend policy document functionality in any of the embodiments herein.

[0245] At 1920, the tenant agreement is reflected in the blockchain service (e.g., provided by Ethereum or other blockchain infrastructure).

[0246] At point 1940, requests for data controlled by one or more protocols are received. For example, a strategy for establishing reference protocols for the data can be developed.

[0247] At 1960, requests to access data were permitted based on a strategy that referenced the blockchain service.

[0248] At subsequent points in time, the blockchain service can be updated to reflect the tenant's protocol changes. Therefore, the request may no longer be granted, or it may be re-granted, etc. In other words, changes to the protocol may lead to changes in whether access is granted according to the policy that references the protocol.

[0249] Example 39 - Exemplary publication use cases

[0250] Figure 20 This is a flowchart of an exemplary sign-off usage example 2000 that can be implemented in any embodiment of this document. Although this embodiment shows "public_access", this usage can cover public shares and tenant-to-tenant shares, and can be combined with... Figure 13 and 14 The method is described similarly.

[0251] The initial phase of publishing resources using access control lists can be driven by an administrative user identifier or process. Control tenant 2010 can interact with identity and access management console 2050, platform 2052, and genomic data service 2054 to complete the publication of public content 2060.

[0252] Subsequent stages of resource retrieval can be driven by a user identifier from another tenant (2020). Access tokens may include membership information (e.g., a role identifier indicating membership). Receiving access may take the form of a list of resources from which actual access can be selected.

[0253] Example 40 - Exemplary permissive tokens

[0254] In any embodiment of this document, an authorization token can associate a role identifier with a resource (e.g., a resource identifier). The role identifier serves as a policy identity that contains policies or rules for data access to the associated resource.

[0255] For example, a resource identifier may be included in an authorization token, associated with a table that maps authorization tokens to resource identifiers, or otherwise linked to the authorization token.

[0256] Example 41 - Exemplary external service provider use cases

[0257] Figure 21 and Figure 22 This is a flowchart illustrating exemplary external service provider use case methods 2100, 2200, which can be implemented in any embodiment herein. Such use cases are comparable to… Figure 15 and 16 The method is described similarly. First, register the external service provider (e.g., as a proxy tenant), and then integrate the external service provider into the system (e.g., using policy-based sharing to allow the external service provider access to the system, whether it is read access, write access, or both).

[0258] In external service provider scenarios, a single policy can enable sharing as described herein. This policy can be defined during the external service provider's registration with the platform. Such a policy may include information such as which combinations of data the external service provider can share. For example, in a scenario where the external service provider uploads data, the policy could allow both the external service provider to upload data and allow access tenants to access data uploaded by the external service provider.

[0259] Data generated by external service providers can be sent to a dedicated tenant (e.g., “tenant_ESP”), and the platform administrator can define a policy for that dedicated tenant to share data with tenants who wish to use the external service provider. When an access tenant generates an access token, the token is encoded with membership-based access permissions, and if the tenant meets the policy conditions, the role identifier specified in the policy is dynamically populated as one of the memberships.

[0260] Shared scenarios can be used to support workflows involving external service providers. A typical workflow that can be initiated involves an external service provider uploading genomic results from an analysis (e.g., a physical biological sample), the external service provider downloading the genomic data, and uploading the results of the analysis (e.g., downloading the genomic data, processing the genomic data externally, and uploading the analysis results). For example, a tenant might want to utilize an external service provider that generates a variant report based on the output from the sequencing process (e.g., a sample file containing base detection and quality information for reads passing through filtering, such as a FASTQ file). The tenant can use the external service provider to run a workflow to upload the sample file. After the upload, the external service provider can run its processes and generate a variant file that the tenant has access to.

[0261] The platform does not need to know the internal workings of the external service provider. Input files can be sent, and the external service provider generates output files that are shared according to the original policy (e.g., rid:<>) when the file was initially uploaded. In this embodiment, the external service provider can read and write to resources (e.g., file storage areas).

[0262] The initial stage of registering external service providers with the platform, such as Figure 21 As shown, and can be driven by a workgroup administrator identifier or process. Administrator user identifier 2110 can interact with platform 2152 and external service provider 2156. Workflow execution service 2153 and genomic data service 2154 can enter at a later time (e.g., integration, access, or both). Although administrator user identifier 2110 can be used by the platform's administrator, tenant administrator identifiers can be granted such permissions if needed (e.g., for registering and integrating external service providers).

[0263] Subsequently, after registration, integration with external service provider 2156 can be provided as part of a workflow involving services from external service provider 2156. In practice, data may be owned by the proxy tenant of external service provider 2156 and shared with other tenants.

[0264] In this embodiment, the platform administrator user identifier 2110 registers the external service provider 2156 with the platform 2152 (e.g., for the scope and permission of the external service provider 2156).

[0265] Then, the administrator user identifier 2110 registers the external service provider 2156 with the dedicated tenant (e.g., a proxy tenant of the external service provider 2156 such as "Tenant_ESP"). In a data write scenario, data processed by the external service provider can be streamed to the dedicated tenant, even if the external service provider may not be a full tenant of the system.

[0266] Then, platform administrator user identifier 2110 can create policy-based access control, enabling tenant-to-tenant data sharing. For example, a proxy tenant can share data with one or more designated tenants.

[0267] An example policy that allows external service providers (“Tenant_ESP”) to share their data with Tenant1 is as follows:

[0268] rid:<tenantESP_tenant1_GUID> (Data owner: Tenant_ESP, but data shared with tenant1 has limited permissions, such as: GDS.FILES.READ)

[0269]

[0270] This strategy is associated with the role identifier “tenantESP_tenant1_GUID”.

[0271] An example policy that allows external service providers (tenant_ESP) to share their data with Tenant1_Clinical_Workgroup is as follows:

[0272] rid:<tenantESP_tenant1_GUID> (Data owner: Tenant_ESP, but data shared with tenant1 has limited permissions, such as: GDS.FILES.READ)

[0273]

[0274] This strategy is associated with the role identifier “tenantESP_tenant1_GUID”.

[0275] After completing the registration, you can implement the following: Figure 22The integration shown involves a common party and a user identifier 2220 from an access tenant (e.g., Tenant1) who wishes to utilize services provided by an external service provider 2256. In exemplary method 2200, the user identifier 2220 from the access tenant initiates a workflow execution task (e.g., communicating with the external service provider 2256) using a workflow execution service 2253. For example, this task might be referred to as "performing an interpretation." In this embodiment, the external service provider 2256 provides results to the access tenant, where providing results includes uploading the results to a genomic data service 2254, where the access tenant can access these results.

[0276] Workflow execution service 2253 sends a request to generate an permission token for external service provider 2256 using a proxy tenant identifier (e.g., "Tenant_ESP"). This token includes an access control list based on a policy. Platform 2252 responds using the permission token, which may take the following common form:

[0277] issuer=platform

[0278] audience=esp

[0279] access control list=[rid:<>]

[0280] tenant id = tenant1

[0281] membership = {}

[0282] The workflow can then invoke the external service provider 2256 using an authorization token that can be verified by the external service provider 2256 (the intended audience of the token) using the public key of the platform configurer or other entity authorized to perform the registration.

[0283] Then, the external service provider 2256 can send a request to platform 2252 to generate an access token for genomic data service 2254, copying the access control list from the access control list statement of the permission token. Platform 2252 responds using the access token, which can take the following general form:

[0284] issuer=platform

[0285] audience=gds

[0286] access control list=[rid:<>]

[0287] membership = {"rid":<>}

[0288] tenant id = tenant_ESP

[0289] Then, the external service provider 2256 can use an access token to upload the results to the genome data service 2254, which can be verified by the genome data service 2254 (the intended audience of the token).

[0290] Subsequently, if the user ID has the appropriate membership enabled by a policy for another tenant's administrator user (e.g., RID:),<tenantESP_tenant1_GUID> If the uploaded data can be accessed by user ID 2220 of the accessing tenant (tenant1) or any other user of the accessing tenant, then the data can be accessed.

[0291] An example policy that allows all users in the access tenant (tenant1) to view processed data from an external service provider is as follows:

[0292] rid:<tenant1_ESP_data_read_access_GUID>

[0293]

[0294] This strategy is associated with the role identifier tenant1_ESP_data_read_access_GUID.

[0295] Therefore, access to data uploaded by external service providers was achieved by using the tenant-to-tenant policy-based sharing technology described in this paper, where the external service providers are assigned proxy tenant identifiers.

[0296] Therefore, the creator of a policy that has resource licensing rights can access any internal or external tenant to obtain a list of identities and resources.

[0297] Example 42 - Exemplary policy version field

[0298] In any of the embodiments described herein, the version field of a policy can be used to facilitate audit trails and roll back a policy to a previous version.

[0299] Example 43 - Exemplary policies

[0300] In any of the embodiments described herein, policies can be used to control sharing. Different policies can be used to achieve different sharing objectives. In the following embodiments, the platform configurer "Illumina" maintains a platform that supports various policy-based sharing scenarios.

[0301] Policies can be associated with role identifiers that ultimately control access to shared resources. A policy can contain one or more identity identifiers (e.g., user identifier, application identifier, workgroup identifier, group identifier), scopes (e.g., permissions), and role identifiers (e.g., one policy can nest another). A policy (rid) can be associated with a resource or identity to allow access to that resource.

[0302] For example, the following strategy can enable any user using a specific application (“Olympia”) to access the content of a supporting application:

[0303] rid:<illumina_app_enabled_data> (Owner: Illumina)

[0304]

[0305] This strategy enables support for application content by including filters that specify the application identifier of the application being considered. Another filter restricts access to certain file types specified in the file type filter (e.g., sam, vcf, bam). As shown in the figure, the strategy is associated with the role identifier "illumina_app_enabled_data".

[0306] In another embodiment, the policy allows sharing public content with anonymous users using a specified application:

[0307] rid:<illumina_public_data> (Owner: Illumina)

[0308]

[0309] This policy enables read-only sharing with any user by specifying a read-only scope and including a wildcard for the tenant identifier. In this embodiment, access is limited to users of the application (“olympia”) specified in the application identifier filter using this policy. However, removing the application filter from the policy will allow read-only access for any user. As shown, this policy is associated with the role identifier “illumina_public_data”.

[0310] In another embodiment, private content is shared with laboratories (workgroups) lab001 and lab002:

[0311] rid:<illumina_private_shared_data> (Owner: Illumina)

[0312]

[0313] This policy enables read-only sharing with any user in either of the two workgroups by specifying a read-only scope and including an explicit list of one or more workgroups. As shown in the figure, this policy is associated with the role identifier "illumina_private_shared_data".

[0314] In another embodiment, tenant user 1 shares data with tenant user 2, who has user identifier "2":

[0315] rid:<tenant1_private_shared_data> (Owner: Tenant1's user-uid:1)

[0316]

[0317] In this embodiment, the policy achieves read-only sharing with the user identifier by specifying a read-only scope and by specifying a specific user identifier in the identity field. As shown in the figure, this policy is associated with the role identifier "tenant1_private_shared_data".

[0318] In another embodiment, the workgroup in tenant1 shares data with users in tenant2 who have limited permissions (i.e., only read and write files):

[0319] rid:<tenant1_workgroup1_private_shared_data> (Owner: Tenant1's workgroup owner)

[0320]

[0321] In this embodiment, the policy is associated with the role identifier “tenant1_workgroup1_private_shared_data”.

[0322] In yet another embodiment, a workgroup in tenant1 shares data with another workgroup in tenant2:

[0323] rid:<tenant1_workgroup1_private_shared_data> (Owner: Tenant1's workgroup owner)

[0324]

[0325] In this embodiment, the policy is associated with the role identifier “tenant1_workgroup1_private_shared_data”, which is reused from the previous embodiment. Therefore, more than one policy can be associated with a role identifier, allowing for stacked policies that can be used to extend access in practice (e.g., policies can be reused across role identifiers to grant similar users access to different resources).

[0326] As shown in the figure, multiple strategies can support various sharing scenarios.

[0327] Example 44 - Exemplary security context

[0328] In any embodiment herein, role identifiers (e.g., role ID, rid, etc.) may alternatively be implemented as security context identifiers (e.g., context ID, cid, etc.).

[0329] Example 45 - Exemplary partners

[0330] In any embodiment herein, parties may collaborate on the platform by sharing genomic digital data. As described herein, such parties may be working groups, tenants, or both. Collaborative working groups may be intra-tenant working groups (e.g., a single tenant) or inter-tenant working groups (e.g., one or more working groups of a tenant collaborating with two or more working groups of another different tenant). Parties may include patients, research laboratories, clinical laboratories (e.g., Quest Diagnostics, LabCorp, etc.), contract laboratories, medical clinics, hospitals, universities, specialists, consultants (e.g., genetic counselors, etc.), companies, genomic service companies (e.g., 23AndMe, Ancestry, etc.), institutions (e.g., the U.S. Centers for Disease Control and Prevention, the U.S. Food and Drug Administration, the European Medicines Agency, the China Food and Drug Administration, the World Health Organization, etc.), etc.

[0331] Example 46 - Exemplary use cases

[0332] The technologies described herein can be used in any of a variety of scenarios implemented in genomic information processing environments and platforms. For example, these technologies can support primary, secondary, and tertiary analysis workflows within or across collaborators. In addition to intra-analytical collaboration, cross-analytical collaboration can be supported, allowing feedback loops of tertiary analysis results to be provided back to the party performing the secondary analysis, enabling recalculation of the secondary analysis based on the tertiary analysis results. The technologies described herein can also be used to implement research-only restrictions or restrictions on diagnostic use for approved clinical use. Furthermore, these technologies can be implemented to ensure compliance with privacy and / or health data residency requirements (e.g., the U.S. Health Insurance Portability and Accountability Act, the European General Data Protection Regulation, the California Consumer Privacy Act, etc.).

[0333] Collaboration and sharing of genomic digital data can be facilitated through policy-based access controls on any of the various workflows that support the above-mentioned aspects of this paper. For example, tenants can collaborate on a workflow, the results of a workflow can be transferred from one tenant to another, and so on.

[0334] Example 47 - Exemplary use cases: primary, secondary, and tertiary analysis

[0335] Sequencing generates vast amounts of genomic digital data, and the associated analytical processes can be complex. Various analytical tools are available to reveal meaningful information within the data in a timely manner. The techniques described in this paper enable collaboration during the use of analytical tools and related workflows, as well as the sharing of workflow results from one tenant to another. One approach to describing the genomic digital data analysis process divides the analysis into three main phases: primary data analysis, secondary data analysis, and tertiary data analysis. Some operations can be automated on the sequencing instrument, while others occur after sequencing is complete.

[0336] Primary data analysis may include analyses performed during the sequencing chemistry and imaging cycle that provide base detections and associated quality fractions representing the major structure of nucleotide chains. In one embodiment, the output of primary data analysis is a BCL base detection file indicating the base detection of nucleotide chain clusters. In practice, this analysis can be performed automatically on the sequencing system. The results of primary analysis may be in the form of genomic digital data represented in a file and uploaded to the cloud for further processing during secondary analysis. Collaboration and sharing can be facilitated through policy-based access controls on such genomic digital data, as described herein. For example, a tenant may perform a primary analysis and grant access to one or more tenants to its results for secondary analysis.

[0337] Secondary analysis can utilize the results of primary analysis, which represents the base detection of unaligned nucleotide fragments, and provides the determination of complete sequences or sequence ranges (e.g., genes) by analyzing and aligning the base detection of nucleotide fragments in the sample, thereby identifying genetic variations. For example, the output of secondary analysis may be in the form of a FASTQ file including sequence information and quality fractions. This analysis typically involves the alignment and assembly of nucleotide fragments. Given a complete sequence or sequence range, variations can be identified. Sequence alignment, variation detection, data visualization, RNA sequencing experiments, gene fusion detection, total RNA expression profiling, and determination of methylated bases can also be performed. Collaboration and gene data sharing during secondary analysis can be facilitated through policy-based access control of genomic digital data, as described herein. For example, a tenant can perform a secondary analysis and grant access to its results to one or more tenants for tertiary analysis.

[0338] Level 3 data analysis may involve using any of a variety of biological data mining and interpretation tools to transform sequence data into knowledge. For example, variation interpretation and diagnosis may be performed on the results of Level 2 analysis. Collaboration and genomic data sharing during Level 3 analysis can be facilitated through policy-based access controls on genomic digital data, as described herein. For example, Level 3 data analysis may include recommendations regarding whether genomic data indicates a patient will respond to a particular drug treatment (e.g., medication, radiation, etc.).

[0339] Example 48 - Exemplary use cases: intra-analysis collaboration

[0340] In any of the embodiments herein, policy-based access control techniques can be used for analytics collaborations where more than one party (e.g., a tenant, a workgroup, or both) collaborates to perform analytics within a phase.

[0341] Example 49 - Exemplary use cases: cross-analysis collaboration

[0342] In any of the embodiments herein, policy-based access control techniques can be used to analyze collaborations where one or more parties (e.g., tenants, workgroups, or both) perform analysis and then provide that analysis to one or more other parties to perform subsequent analysis at different stages.

[0343] In this scenario, the feedback loop of the tertiary analysis results can be provided back to the party performing the secondary analysis, allowing for modifications to be made to rerun the secondary analysis. The secondary analysis results can then be updated so that (e.g., by the same or one or more other parties) the tertiary analysis can be modified or rerun.

[0344] Example 50 - Exemplary use cases: government agency approved

[0345] Instruments and tests

[0346] In any of the embodiments described herein, policy-based access control techniques can be used to implement diagnostic processing for government-approved diagnostic instruments and / or tests among tenants. For example, FDA-approved instruments and / or tests may be performed in scenarios involving multiple tenants who share data during testing.

[0347] Example 51 - Exemplary use cases: research processing

[0348] Access controls as described herein can enforce research-only processing. For example, research-only processing can be performed by tenants or workgroups within a tenant in a genomic digital data sharing scenario across institutional and geographical boundaries while protecting data security. For instance, access to individual patient identifiers can be restricted so that data processing is not associated with a specific individual.

[0349] Example 52 - Example Use Case: Privacy and Data Residency

[0350] In addition, access controls can be implemented to ensure complex privacy and / or health data residency (e.g., geolocation) requirements. For example, in a research scenario, individual health data with directly identifiable information can be intercepted or restricted, while aggregated health datasets with identifiable information can be published or pushed to third-party providers or other tenants for analysis.

[0351] In diagnostic scenarios, individual health data with directly identifiable information can be used.

[0352] For example, access tokens can be used to ensure that other parties (third-party analytics providers) no longer have access to shared data when the token expires or is revoked. Revocation can be performed upon completion of processing or at the patient's instruction.

[0353] For example, access tokens can be used to ensure that data resides in a specific geographic location or region.

[0354] Example 53 - Example Advantages

[0355] Policy-based sharing technologies offer numerous advantages. For example, the ease of implementation in a policy-based sharing environment often encourages sharing among tenants. Due to the late-binding nature of role identifiers, there is no need to store a full mapping of users or tenants to roles. Instead, roles can be bound at runtime. This reduces the overall storage requirements for security data.

[0356] Similarly, the flexibility of policy-based role assignment allows for the incorporation of new standards without having to redesign the platform or complicate tenant management.

[0357] Binding roles at runtime also provides more accurate role assignment. For example, changes to a tenant's status or service level are reflected immediately, rather than some time after the pre-mapped roles have been reassigned.

[0358] Another advantage is that executable workflows can be shared along with the underlying data on which they are executed. Therefore, tenants can share underlying data, execute shared workflows on such data, and receive analytics results. Workflows can also invoke external service providers, enabling fully collaborative scenarios that would be impossible without such technology.

[0359] Trust relationships can be enforced via signature tokens as described herein. Therefore, the security of underlying data is guaranteed, enabling tenant-to-tenant sharing while maintaining the reliability of the underlying data. Access auditing is also possible, and audit logs can be used for testing, security, or compliance purposes.

[0360] Software testing can also be made easier by easily setting up test tenants and sharing data with them, providing proof-of-concept and quality assurance testing for shared scenarios, and then extending to real tenants outside the test scenarios.

[0361] Example 54 - Example Computing System

[0362] FIG. 23 Embodiments of a suitable computing system 2300 are described, in which the digital aspects of the aforementioned innovations can be implemented. The computing system 2300 is not intended to imply any limitation on the scope or functionality of this disclosure, as these innovations can be implemented in a wide variety of different computing systems.

[0363] refer to FIG. 23 The computing system 2300 includes one or more processing units 2310, 2315, and memories 2320, 2325. FIG. 23 In this document, the basic configuration 2330 is included within the dashed lines. The one or more processing units execute computer-executable instructions, such as those for implementing the features described in the embodiments herein. The one or more processing units 2310, 2315 can be any combination or central processing unit (CPU), graphics processing unit (GPU), single-core processor, multi-core processor, application-specific integrated circuit (ASIC), programmable circuitry such as field-programmable gate array (FPGA), etc. In addition to hardware implementation, one or more of the processing units 2310, 2315 can be implemented in software (e.g., ultimately executed on hardware) and / or firmware.

[0364] In a multiprocessor system, multiple processing units execute computer-executable instructions to enhance processing power. Physical memories 2320 and 2325 may be volatile memory (e.g., registers, cache, RAM), non-volatile memory (e.g., ROM, EEPROM, flash memory, etc.), or some combination thereof, accessible by processing units 2310 and 2315. Memories 2320 and 2325 store one or more innovative software 2380 implementing the invention in the form of computer-executable instructions suitable for execution by one or more processing units 2310 and 2315.

[0365] The function can also be performed at least partially by one or more hardware logic components. For example, Field Programmable Gate Arrays (FPGAs), Application Standard Products (ASSPs), Systems on Chips (SoCs), Complex Programmable Logic Devices (CPLDs) can be used.

[0366] The computing system 2300 may have additional features. For example, the computing system 2300 includes a storage device 2340, one or more input devices 2350, one or more output devices 2360, and one or more communication connections 2370, including input devices, output devices, and communication connections for user interaction. Interconnection mechanisms (not shown), such as buses, controllers, or networks, interconnect the components of the computing system 2300. Typically, operating system software (not shown) provides an operating environment for other software executing in the computing system 2300 and coordinates the activities of the components of the computing system 2300.

[0367] The physical storage device 2340 may be removable or non-removable and includes a disk, magnetic tape or tape cartridge, CD-ROM, DVD, or any other medium that can be used to store information in a non-transitory manner and is accessible within the computing system 2300. The storage device 2340 stores instructions for the software 2380 to implement one or more of the innovations described herein.

[0368] Input device 2350 may be an input device such as a keyboard, mouse, pen or trackball, voice input device, scanning device, touch device (e.g., touchpad, display, etc.) or another device that provides input to computing system 2300. Output device 2360 may be a display, printer, speaker, CD burner, or another device that provides output from computing system 2300.

[0369] Communication connection 2370 enables communication with another computing entity via a communication medium. This communication medium transmits information, such as computer-executable instructions, audio or video input or output, or other data, in modulated data signals. A modulated data signal is a signal in which one or more of its characteristics are set or altered in a manner that encodes information in the signal. By way of example and not limitation, the communication medium may be electrical, optical, RF, or other carrier waves.

[0370] Innovations can be described in the context of computer-executable instructions, such as those included in program modules that execute on a target real or virtual processor in a computing system (e.g., ultimately on one or more hardware processors). Typically, program modules or components include routines, programs, libraries, objects, classes, components, data structures, etc., that perform specific tasks or implement specific abstract data types. In various implementations, the functionality of program modules can be combined as needed or divided among program modules. The computer-executable instructions for program modules can execute within a local or distributed computing system.

[0371] For ease of explanation, the terms "determine" and "use" are used in detail to describe computer operations in a computing system. These terms are high-level descriptions of operations performed by the computer and should not be confused with human actions. The actual computer operations corresponding to these terms vary depending on the specific implementation.

[0372] Example 55 - Computer-Readable Medium

[0373] Any computer-readable medium described herein may be non-transitory (e.g., volatile memory such as DRAM or SRAM, non-volatile memory such as magnetic storage devices, optical storage devices, etc.) and / or tangible. Any storage action described herein may be performed by storage in one or more computer-readable media (e.g., computer-readable storage media or other tangible media). Anything described as stored (e.g., data created and used during implementation) may be stored in one or more computer-readable media (e.g., computer-readable storage media or other tangible media). Computer-readable media may be limited to specific implementations that do not consist of signals.

[0374] Any method described herein may be implemented by computer-executable instructions (e.g., stored thereon, encoded thereon, etc.) in one or more computer-readable media (e.g., computer-readable storage media or other tangible media) or one or more computer-readable storage devices (e.g., memory, magnetic storage device, optical storage device, etc.). Such instructions can cause a computing system to perform the method. The techniques described herein can be implemented using a variety of programming languages.

[0375] Example 56 - Example Cloud Computing Environment

[0376] FIG. 24 An exemplary computing environment 2400 in which the technology described herein may be implemented is depicted, including, for example... FIG. 1 System 100 and other systems described herein. Cloud computing environment 2400 includes cloud computing service 2410. Cloud computing service 2410 may include various types of cloud computing resources, such as computer servers, data storage repositories, networking resources, etc. Cloud computing service 2410 may be centrally located (e.g., provided by a business or organization's data center) or distributed (e.g., provided by various computing resources located in different locations, such as different data centers and / or located in different cities or countries).

[0377] Cloud computing service 2410 is utilized by various types of computing devices (e.g., client computing devices), such as computing devices 2420, 2422, and 2424. For example, computing devices (e.g., 2420, 2422, and 2424) can be computers (e.g., desktop computers or laptop computers), mobile devices (e.g., tablets or smartphones), or other types of computing devices. For example, computing devices (e.g., 2420, 2422, and 2424) can utilize cloud computing service 2410 to perform computing operations (e.g., data processing, data storage, etc.).

[0378] In practice, it can support cloud-based scenarios, on-site scenarios, or hybrid scenarios.

[0379] Example 57 - Example Implementation

[0380] Although some of the operations of the disclosed methods have been described in a specific order for demonstration purposes, this description may be rearranged unless the specific language described herein requires a particular order. For example, in some cases, the operations described in the order may be rearranged or executed concurrently.

[0381] Example 58 - Example Implementation

[0382] Any of the following implementation schemes may be implemented.

[0383] Clause 1. A method comprising:

[0384] In a computing system comprising multiple tenants, the multiple tenants seek access to a genomic digital data resource provided by one or more genomic data services in a software as a service platform, which encodes access to the genomic digital data resource via policy-based access control, and receives a policy-based access control definition for the first tenant among the tenants of a given genomic digital data resource.

[0385] Receive a request to access a given genome digital data resource from a second tenant among tenants seeking access to that resource; and

[0386] For the second tenant among the tenants, access to the given genomic digital data resource is permitted based on the policy-based access control definition.

[0387] Clause 2. The method described in Clause 1, wherein:

[0388] Access to a given genomic digital data resource is controlled by role identifiers linked to that policy-based access control definition; and

[0389] The method further includes:

[0390] In response to the access request, provide the role identifier specified in the policy-based access control definition.

[0391] Clause 3. The method described in Clause 2, wherein:

[0392] Assigning a role identifier includes later binding the role identifier to the user identifier or tenant identifier of the access request.

[0393] Clause 4. The method according to any one of Clauses 2 to 3 further includes:

[0394] In response to the access request, a signed access token containing a role identifier is generated;

[0395] Access is granted based on the presence of a role identifier in the signature access token.

[0396] Clause 5. The method described in accordance with Clause 4, wherein:

[0397] Further access is granted based on verification of the signed access token.

[0398] Clause 6. The method according to any one of Clauses 4 to 5 further includes:

[0399] Issue a signature permission token, which includes a role identifier and a tenant identifier for the role administrator;

[0400] This involves determining whether the tenant identifier, based on the signature-granted token, has sufficient permissions to grant further access to the resources specified for the role identifier.

[0401] Clause 7. The method according to any one of Clauses 1 to 6, wherein the first tenant among the tenants includes a proxy tenant that represents an external service provider for whom policy-based sharing is implemented.

[0402] Clause 8. The method according to any one of Clauses 1 to 7, wherein the policy-based access control definition includes indexing of the smart contract.

[0403] Clause 9. The method according to any one of Clauses 1 to 8, wherein the policy-based access control definition includes indexing of the service level of a second tenant among the tenants, and grants access based on the service level of the second tenant among the tenants determined at the time of request.

[0404] Clause 10. The method according to any one of Clauses 1 to 9, wherein the policy-based access control definition specifies one or more access control statements including filter attributes and filter parameters.

[0405] Clause 11. The method described in Clause 10, wherein the filter parameter specifies a wildcard for the filter attribute.

[0406] Clause 12. The method according to any one of Clauses 10 to 11, wherein the filter attribute includes the application.

[0407] Clause 13. The method according to any one of Clauses 10 to 12, wherein the filter attribute includes an application role identifier.

[0408] Clause 14. The method according to any one of Clauses 1 to 13, wherein the policy-based access control definition supports access control statements that specify access results, tenant identifiers, and one or more conditions for granting access.

[0409] Clause 15. The method according to any one of Clauses 1 to 14, wherein the policy-based access control definition supports public access, private access, and application-based access.

[0410] Clause 16. The method according to any one of Clauses 1 to 15, wherein the policy-based access control definition includes parameters evaluated at execution time.

[0411] Clause 17. The method described in accordance with Clause 16, wherein:

[0412] Policy-based access control defines parameters including the application identifier parameter; and

[0413] Granting access involves comparing the application identifier parameter defined in the policy-based access control with the application identifier specified by a second tenant among the tenants seeking access to the genomic digital data resource.

[0414] Clause 18. The method according to any one of Clauses 16 to 17, wherein:

[0415] Policy-based access control defines parameters including the tenant identifier parameter; and

[0416] Granting access involves comparing the tenant identifier parameter of the access control definition with the tenant identifier of a second tenant seeking access to the genomic digital data resource.

[0417] Clause 19. A cloud-based multi-tenant system, the system comprising:

[0418] One or more processors;

[0419] Memory, the memory being coupled to the one or more processors;

[0420] A policy repository that includes policy-based access control definitions received for the first tenant and includes role identifiers;

[0421] Links to the genomic digital data resources for this role identifier;

[0422] The memory includes computer-executable instructions that cause the one or more processors to perform operations, including:

[0423] Receive a request to access the genomic digital data resource from a second tenant seeking access to that resource; and

[0424] For the second tenant, access to the genomic digital data resource is permitted based on the policy-based access control definition evaluated at the time of the access request.

[0425] Clause 20. One or more computer-readable media, including:

[0426] A computer-executable instruction that enables a computing system to receive a publishing request to a first tenant to provide access to genomic digital data, wherein access to the genomic digital data is controlled by a role identifier linked to a policy document, wherein the policy document includes one or more conditions.

[0427] A computer-executable instruction that enables a computing system to receive a request from a second tenant to access the genomic digital data, the access to the genomic digital data being controlled by a role identifier linked to the policy document, wherein the request includes one or more attributes;

[0428] Computer-executable instructions that enable the computing system to access the policy document in response to the request from the second tenant; and

[0429] Computer-executable instructions that enable the computing system to generate an access token based on one or more attributes and one or more conditions, wherein a role identifier is included in the access token in response to determining that one or more attributes satisfy one or more conditions, and the access token authorizes access to the genomic digital data via the role identifier.

[0430] Clause 21. One or more computer-readable media, including computer-executable instructions that, when executed by a computing system, cause the computing system to perform the method according to any one of Clauses 1 to 18.

[0431] Example 58 - Example Alternative Implementation

[0432] The techniques from any embodiment may be combined with the techniques described in any one or more other embodiments. Given the many possible implementations to which the principles of the disclosed techniques can be applied, it should be understood that the illustrated embodiments are examples of the disclosed techniques and should not be considered as limiting the scope of the disclosed techniques. Rather, the scope of the disclosed techniques includes the scope and substance covered by the following claims.

Claims

1. A computer-implemented method for policy-based genomic data sharing, the method comprising: providing access to genomic digital data resources provided by one or more genomic data services in a software-as-a-service platform; orchestrating access to the genomic digital data resources by a plurality of tenants via policy-based access control; receiving a policy-based access control definition for a first one of the tenants of a given genomic digital data resource, wherein the genomic digital data resource comprises genomic data originating from a sequencing instrument, and the policy-based access control definition supports access control statements that specify one or more conditions under which access is permitted; receiving a request for access to the given genomic digital data resource from a second one of the tenants seeking access to the given genomic digital data resource, wherein the request comprises one or more attributes; in response to the request from the second tenant, accessing the policy-based access control definition; generating an access token based on the one or more attributes and the one or more conditions; adding a role identifier of the policy-based access control definition to the access token; and permitting access to the given genomic digital data resource by the second tenant based on the policy-based access control definition.

2. The method of claim 1, wherein: access to the given genomic digital data resource is controlled by a role identifier linked to the policy-based access control definition; and the method further comprises: in response to the request for access, providing the role identifier specified in the policy-based access control definition for the request for access.

3. The method of claim 2, wherein: assigning the role identifier comprises late-binding the role identifier to a user identifier or tenant identifier of the request for access.

4. The method of any one of claims 2-3, further comprising: in response to the request for access, generating a signed access token containing the role identifier; wherein access is permitted based on the presence of the role identifier in the signed access token.

5. The method of claim 4, further comprising: issuing a signed permission token comprising the role identifier and a tenant identifier of a role administrator of the role identifier; wherein access is further permitted based on whether the tenant identifier of the signed permission token has sufficient permissions to specify resources for the role identifier.

6. The method of claim 1, wherein the first one of the tenants comprises a proxy tenant on behalf of an external service provider for which policy-based sharing is implemented.

7. The method of claim 1, wherein the policy-based access control definition specifies one or more access control statements comprising a filter attribute and a filter parameter.

8. The method of claim 7, wherein the filter parameter specifies a wildcard for the filter attribute.

9. The method of claim 7, wherein the filter attribute comprises an application. ​ ​ 10. The method of claim 7, wherein the filter attribute comprises an application role identifier.

11. The method of claim 1, wherein the policy-based access control definition comprises a parameter that is evaluated at execution time.

12. The method of claim 11, wherein: the parameter of the policy-based access control definition comprises an application identifier parameter; and granting access comprises comparing the application identifier parameter of the policy-based access control definition to an application identifier specified by the second one of the tenants seeking access to the genomic digital data resource.

13. The method of claim 11, wherein: the parameter of the policy-based access control definition comprises a tenant identifier parameter; and granting access comprises comparing the tenant identifier parameter of the access control definition to a tenant identifier of the second tenant seeking access to the genomic digital data resource.

14. One or more computer-readable media comprising computer-executable instructions that, when executed by a computing system, cause the computing system to perform the method of any one of claims 1-13.

15. A cloud-based multi-tenant system, the system comprising: one or more processors; memory coupled to the one or more processors; a policy store comprising a policy-based access control definition received for a first tenant, a role identifier, and one or more conditions; a sequencing instrument; a genomic digital data resource linked to the role identifier, wherein the genomic digital data resource comprises genomic data derived from the sequencing instrument; wherein the memory comprises computer-executable instructions that cause the one or more processors to perform operations comprising: receiving a request for access to the genomic digital data resource from a second tenant seeking access to the genomic digital data resource, wherein the request comprises one or more attributes; in response to the request from the second tenant, accessing the policy-based access control definition; generating an access token based on the one or more attributes and the one or more conditions; in response to determining that the one or more attributes satisfy the one or more conditions, the role identifier is added to the access token; and granting access to the genomic digital data resource to the second tenant in accordance with the policy-based access control definition evaluated at the time of the request for access.

Images