Policy-based genomic data sharing for software-as-a-service tenants

Abstract

Policy-based genomic digital data sharing facilitates a variety of sharing scenarios, including public access, inter-tenant sharing, workgroup sharing, and access by external service providers. Genomic digital data can be published to the platform and controlled by access tokens generated based on access policies. Policies support conditions that are evaluated at runtime, effectively placing control of access to information in the hands of the owning tenant. Sharing conditions can be easily specified to support a variety of use cases, freeing operators from excessive access control configurations.

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application claims the benefit of U.S. Provisional Patent Application No. 63 / 045,736, filed June 29, 2020, which is incorporated herein by reference.

[0002] FIELD OF THE INVENTION The technical field generally relates to sharing data between software-as-a-service (SAAS) tenants. [Background technology]

[0003] Research on genomic data can involve complex analysis by various parties with different expertise collaborating over time. Research typically begins with genomic data, which may come from a variety of sources. A wide variety of techniques can then be used to analyze the data. Today's research projects can involve parties spread across the globe sharing and / or collaborating on data analysis. While progress has been made in the field and international standards for sharing genomic data have been developed, significant challenges to sharing genomic data remain. Summary of the Invention

[0004] This Summary is provided in a simplified form to introduce various concepts that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0005] In one embodiment, a method, in a software-as-a-service platform that orchestrates access to genomic digital data resources through policy-based access control, in a computing system having a plurality of tenants seeking access to genomic digital data resources provided by one or more genomic data services, includes receiving a policy-based access control definition for a first one of the tenants for a given genomic digital data resource, 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, and granting access to the given genomic digital data resource for the second one of the tenants based on the policy-based access control definition.

[0006] In another embodiment, a multi-tenant cloud-based system comprises one or more processors; memory coupled to the one or more processors; a policy store including a policy-based access control definition received for a first tenant and including a role identifier; and 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, the operations including 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 for the second tenant in accordance with the policy-based access control definition that is evaluated at the time of the access request.

[0007] In another embodiment, one or more computer-readable media include computer-executable instructions that can cause a computing system to receive a publication request to provide access to genomic digital data for a first tenant, where access to the genomic digital data is controlled by a role identifier linked to a policy document, the policy document including one or more conditions; computer-executable instructions that can cause the computing system to receive a request for access to the genomic digital data from a second tenant, where the access is controlled by the role identifier linked to the policy document, the request including one or more attributes; computer-executable instructions that can cause the computing system to access the policy document in response to the access request from the second tenant; and computer-executable instructions that can cause the computing system to generate an access token based on the one or more attributes and the one or more conditions, where in response to determining that the one or more conditions are satisfied by the one or more attributes, the role identifier is included in the access token and the access token grants access to the genomic digital data via the role identifier. [Brief explanation of the drawings]

[0008] [Figure 1] FIG. 1 is a block diagram of an exemplary system implementing policy-based genomic digital data sharing. [Figure 2] 1 is a flowchart of an exemplary method for implementing policy-based genomic digital data sharing. [Figure 3] FIG. 1 is a block diagram of an exemplary system including a platform that implements policy-based genomic digital data sharing via signed access tokens. [Figure 4] 1 is a flowchart of an exemplary method for implementing policy-based genomic digital data sharing via signed access tokens. [Figure 5]FIG. 1 is a block diagram of an example system for generating a signed access token based on an access request and a policy document. [Figure 6] 1 is a flowchart of an example method for generating a signed access token based on an access request and a policy document. [Figure 7] A visualization of supported scenarios. [Figure 8] FIG. 2 is a block diagram of an example policy document. [Figure 9] FIG. 1 is a block diagram of an example signed access token. [Figure 10] FIG. 1 is a block diagram of an example system for generating an access token based on attributes of an access request and conditions of a policy document. [Figure 11] 1 is a flowchart of an exemplary method for generating an access token based on attributes of an access request and conditions of a policy document. [Figure 12] FIG. 1 is a block diagram of a system for publishing genomic content for policy-based sharing. [Figure 13] 1 is a flowchart of an exemplary method for publishing genomic content for policy-based sharing. [Figure 14] 1 is a flowchart of an exemplary method for accessing publicly shared genomic content. [Figure 15] 1 is a flowchart of an exemplary method for registering an external service provider. [Figure 16] 1 is a flowchart of an exemplary method for integrating external service providers into a policy-based sharing platform. [Figure 17] FIG. 1 is a block diagram of an example system for verifying signed access tokens. [Figure 18] FIG. 1 is a block diagram illustrating the integration of smart contracts into a policy-based sharing platform. [Figure 19] 1 is a flowchart of an exemplary method for implementing smart contracts in a policy-based sharing platform. [Figure 20] FIG. 1 is a flow diagram of an exemplary disclosure use case. [Figure 21] FIG. 10 is a flow diagram of an example external service provider use case involving registration. [Figure 22] FIG. 1 is a flow diagram of an example external service provider use case involving integration. [Figure 23] FIG. 1 is a block diagram of an exemplary computing system in which the described embodiments may be implemented. [Figure 24] FIG. 1 is a block diagram of an exemplary cloud computing environment that can be used in conjunction with the techniques described herein. DETAILED DESCRIPTION OF THE INVENTION

[0009] Example 1 - Overview The ever-growing availability of genomic data presents new opportunities for research and analysis. Today's sequencing platforms can generate a wide variety of sequence outputs, including whole-genome sequencing (WGS). Various organizations, such as the Global Alliance for Genomics & Health, have developed standards for sharing genomic data. However, in practice, today's genomic information ecosystem can sometimes appear fractured. Data can be separated or siloed due to various considerations, including technical, security, legal, and financial reasons. Even when data is publicly available, it may not be fully integrated to be immediately useful.

[0010] One major hurdle is sharing information between parties. A completely open platform that allows every participant to share all of every other participant's data is neither realistic nor desirable. However, a policy-based approach to sharing genomic digital data between software-as-a-service tenants can enable parties to share data in a controlled way that fosters collaboration between parties. Public data can be included, and external service providers can participate. Access control can be automated and more easily controlled, without the need for lengthy and complex manual security operations.

[0011] As a result, cloud-based platforms can act as virtual spaces where actors from diverse backgrounds and institutions can collaborate and share data, knowledge, tools, workflows, and applications to converge on innovative insights and arrive at new solutions.

[0012] Freed from technological limitations, data can move where it is needed, potentially resulting in a more collaborative ecosystem. As the technology applies to genomic digital data generally, it can be applied across numerous use cases involving the storage, retrieval, and analysis of genomic digital data.

[0013] Example 2 - Exemplary System Implementing Policy-Based Genomic Digital Data Sharing 1 is a block diagram of an exemplary system 100 that implements policy-based genomic digital data sharing. In an example, multiple tenants 110A-N with associated user identifiers 120 access an application hosting platform instance 135 running on a data center 130. The platform instance 135 includes a platform authentication service 140, multiple hosted applications 150A-N, an operations service 158, a policy store 160 (e.g., having policy documents described herein), and an authentication token 170. As described herein, some scenarios may include trust documents (not shown) that may affect policy-based access to genomic digital data.

[0014] Applications 150A-N as part of their processing may access one or more genomic data services 190A-N, which typically provide genomic digital data.

[0015] In practice, systems illustrated herein, such as system 100, may vary in complexity with additional 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 implement security, redundancy, load balancing, report design, etc.

[0016] The described computing systems may be networked via wired or wireless network connections, including the Internet, or the systems may be connected via intranet connections (e.g., in corporate, government, etc. environments).

[0017] System 100 and any of the other systems described herein may be implemented in conjunction with any of the hardware components described herein, such as the computing systems (e.g., processing units, memories, etc.) described below. In any of the examples herein, genomic digital data, policy documents, authentication tokens, etc. may be stored on one or more computer-readable storage media or devices. The techniques described herein may be general to operating system or hardware details and may be applied in any of a variety of environments to take advantage of the features described.

[0018] Example 3 - Exemplary Method for Implementing Policy-Based Genomic Digital Data Sharing FIG. 2 is a flowchart of an exemplary method 200 that implements policy-based genomic digital data sharing and may be performed, for example, by the system of FIG. 1 (eg, application hosting platform instance 135).

[0019] At 210, a new tenant 210 is onboarded. As a result, the tenant is assigned a tenant identifier and is given the ability to share genomic digital data via the tenant identifier. In practice, such onboarding can occur any time before a request to publish data for sharing is received and need not be considered part of the publication / access scenario.

[0020] At 220, the platform receives a request from a tenant to publish genomic digital data within the system, the request including a policy document that controls sharing. In a software-as-a-service platform that orchestrates access to genomic digital data resources through policy-based access control, in a computing system with multiple tenants seeking access to genomic digital data resources provided by one or more genomic data services, a policy-based access control definition (e.g., a policy document) of a first one of the tenants for a given genomic digital data resource can be received. The definition can be received from the first one of the tenants or another party (e.g., in an external service provider scenario).

[0021] A request to access the shared genomic digital data is received from another tenant at 240. A request to access the given genomic digital data resource is received from a second one of the tenants seeking access to the given genomic digital data resource.

[0022] At 250, a request to access the shared genomic digital data is granted based on (e.g., in accordance with) a policy document configured by the owning tenant (e.g., the tenant that shared the data). Access is granted based on a policy-based access control definition. As described herein, a token may be provided in the request for access. The token may be generated based on an associated policy and then used to control access to the data (e.g., using a role identifier 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.

[0023] In practice, a single party (e.g., operating the platform) can perform all of the actions shown; however, it is also possible for one party to perform only some actions (e.g., onboarding) and another to perform others (e.g., granting). Division of tasks can also be along domain lines (e.g., one party performs functions related to publishing and another performs functions related to granting access).

[0024] The illustrated actions can be interpreted from alternative perspectives while implementing the technology, for example, "receiving a request" can also be interpreted as "sending a request" from the tenant's perspective.

[0025] Method 200 and any of the other methods described herein may be implemented by computer-executable instructions stored on one or more computer-readable media (e.g., storage devices or other tangible media) or stored on one or more computer-readable storage devices (e.g., causing a computing system to perform the instructions). Such methods may be implemented in software, firmware, hardware, or a combination thereof. Such methods may be at least partially implemented by a computing system (e.g., one or more computing devices).

[0026] When implemented on a computer-readable medium, the techniques may include computer-executable instructions that can cause a computing system to perform each of the method steps.

[0027] Example 4 - Exemplary Genomic Digital Data In any of the examples herein, genomic digital data may be subject to policy-based sharing. Such data may take the form of sequenced DNA, RNA, etc. (For example, the output of a sequencer takes the form of a digital representation of strands of DNA, typically consisting of the four nucleotides adenine (A), cytosine (C), guanine (G), and thymine (T). Nucleotides can be represented digitally in a variety of ways and encodings, but typically have equivalent string representations of A's, C's, G's, and T's, which are used for convenience of explanation. While a DNA example is given, RNA sequencing can be used as well. Similarly, the term "genomic" encompasses information from genomes, exomes, and transcriptomes.

[0028] In practice, sequence information is accompanied by other useful information for research, including substantive data such as the source of the DNA (e.g., subject demographics, subject pathology, etc.). Disease and phenotype information can be included and / or associated with the genomic digital data. Sequencing metadata can also be included (e.g., the machine / instrument and technique used to sequence the DNA, the sequenced data, sequencing yield, quality metrics, a pointer to the sequencing run record, etc.). Other metadata, such as the name of the originating party, legal restrictions, etc., can also be included.

[0029] To facilitate sharing, data may be provided in a common format that allows analytics and workflows to be used across tenants, which may be proprietary or open to facilitate the open exchange of information in sharing scenarios.

[0030] Policy-based sharing can be extended to other genomic data, such as executable workflow definitions related to genomic digital data. Thus, tenants can access both executable workflows for processing genomic digital data as well as the underlying data itself through the policy-based sharing techniques described herein. A shared executable workflow definition can originate from one source (e.g., a tenant), while the underlying data originates from the same or a different source (e.g., the same or a different tenant). Such executable workflows can be associated with established protocols for reliability, consistency of results, etc. Thus, for a particular research project, a given executable workflow can be shared among participants. Custom executable workflows can be developed by tenants and shared similarly.

[0031] Executable workflows can be executed (e.g., interpreted) by an engine or service that interfaces with sequencing equipment, thereby 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 aimed at various sequencing and related analytical tasks, such as demultiplexing, mapping and aligning, position sorting, duplicate marking, variant calling, etc. Specialized workflows devoted to tumor-only or tumor-normal modes can be designed to detect somatic variants in tumor samples. Many other scenarios are possible.

[0032] Due to the long computation times and large amounts of data, such workflows can provide speed, flexibility, and cost-effectiveness, allowing laboratories of various sizes and disciplines to better leverage their genomic data. The sharing techniques described herein can better leverage such data across tenants.

[0033] For convenience, the shared genomic digital data may be referred to as a "resource" or a "protected resource," indicating that the data is a resource to which access is controlled via the policies described herein.

[0034] Genomic digital data may be provided by a genomic data service, which may enforce access controls and cooperate with the platform to recognize and validate access tokens, as described herein.

[0035] Example 5 - Exemplary Software Tenant Any of the embodiments herein may support a variety of software tenants, which may conveniently be referred to as "tenants." Such tenants typically take the form of enterprise tenants, such as businesses, government entities, research institutions or groups, educational institutions or groups, user organizations, etc. By utilizing the techniques described herein, such tenants can significantly benefit from policy-based sharing.

[0036] Any given user of the platform can be assigned to a tenant. In a multi-tenant cloud system, users can share computing resources but have a personalized and customizable user experience and individual stored data. In practice, a tenant tends to represent a single legal entity that has a single agreement with the platform provider. Thus, a user identifier is typically associated with a single tenant, and services are provided to the user based on the agreement between the cloud provider and the tenant.

[0037] Tenants may share computing resources operated by the cloud service provider, but the distinguishing factor between tenants is that different tenants may have different subscriptions, different storage limits, and levels of access to the platform's genomic digital data and services. Various other customizations can be made. Tenants are not necessarily application owners, as the application owner may be the cloud provider or a third party. However, some tenants may develop their own applications.

[0038] In cloud-based scenarios, the framework is provided transparently to users to leverage redundancy of functionality and processes between tenants. However, boundaries between tenants may be enforced to prevent one tenant from accessing another tenant's data. Each tenant's data may be isolated and remain invisible to other tenants. Such arrangements are typically a fundamental characteristic of multi-tenant systems. However, while such isolation is typically desirable, for some data, there are significant advantages to enabling policy-based sharing between tenants as described herein.

[0039] Thus, the described platform can have characteristics of a traditional cloud-based multi-tenant system, but can also enable controlled sharing between and among tenants, including the proxy tenants described herein.

[0040] Example 6 - Exemplary Proxy Tenant In any of the embodiments herein, a proxy tenant can be implemented. The proxy tenant can be registered as a tenant and can have a tenant identifier, but the tenant identifier is not used in the capacity of normal tenant functionality, regardless of whether the entity being represented is an actual tenant of the platform. For example, in a public sharing scenario, because the data is public, a proxy tenant can be set up for public data, regardless of whether the source (e.g., owner) of the data is actually involved (e.g., a website, government agency, foundation, etc.). The proxy tenant has a tenant identifier, and the digital genome digital data can be published under the tenant identifier. In this way, public sharing scenarios can be supported by the platform. In practice, the data-owning proxy tenant may also have an actual tenant identifier. In that way, an organization may have multiple tenant identifiers, one used in the capacity as a source of public genome digital data, another used in the capacity as a research institution using normal tenant functionality, etc.

[0041] Similarly, in an external service provider scenario, a proxy tenant can be set up for the external service provider. The external service provider can be assigned a tenant identifier that can be used to access and upload data to the platform for sharing under the tenant identifier. In this way, the external service provider can be supported by the system. Again, the external service provider can also have an actual tenant identifier that is used when the external service provider acts in the capacity of a regular tenant.

[0042] Finally, a platform operator or other similar party may act in the capacity of a tenant or tenant agent to provide any of the tenant-based features described herein. Such an arrangement may be useful in cases where a tenant is unwilling, unavailable, or unable to engage with the platform.

[0043] Thus, in any of the embodiments herein, 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 achieve policy-based sharing.

[0044] Example 7 - Exemplary Roll In any of the examples herein, roles can be used to control access to shareable genomic digital data. As described herein, roles can be uniquely identified by a role identifier. Such a role identifier can be created when a tenant wants to expose a resource for sharing and can be linked to a policy document for a given resource.

[0045] Example 8 - Exemplary Role Bindings To achieve 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 (e.g., when access to a resource is requested, when a list of available resources is requested, etc.) instead of upfront. In this way, role assignments can be dynamic in that if policies change, role assignments can also change automatically. Thus, roles can change over time without explicitly specifying a particular user. A user's membership in a tenant or workgroup can change role assignments if policies reference such attributes. As described herein, binding can occur on demand and can be based on the user identifier or tenant identifier of the request.

[0046] Similarly, policy-based sharing means that any change to the policy can result in a change to the share (e.g., role assignment). Policies that further depend on other factors (e.g., agreement status, agreement level, subscription status, subscription level, etc.) can cause changes to role assignments if such factors change. For example, if a tenant obtains a new subscription level, users from the tenant can be automatically granted additional access because the next time a user of the tenant requests access, roles can be assigned at runtime.

[0047] Thus, the late binding of roles and the dynamic nature of role assignment can support a wide variety of flexible and automated scenarios that avoid the prior assignment of individual roles to specific users, thus significantly reducing the resources required to operate the system while providing such rich functionality.

[0048] Additional roles may be provided at the application level (e.g., enforced by the application). Such roles may have early or late binding. For example, an application role identifier may specify lab manager, supervisor, assistant, etc. The application role identifier itself may be used in condition statements that control access to policy-based roles. In such cases, in response to determining that an access request has an attribute indicating a role identifier that satisfies the condition specified in the policy document, the role is included in the appropriate permissions (e.g., as specified for the role) in the signed access token.

[0049] Example 9 - Exemplary Authorization In any of the embodiments herein, permission to share a resource can be specified by specifying a service type, a resource type, and a permission type (e.g., "GSS FILES.UPDATE", "GSS.LIBRARYPOOLS.READ", etc.).

[0050] Permission types may include manage, archive, create, delete, destroy, download, hide, lock, read, update, write, administer, run, grant, etc. Resource types may include subscription, file, sequencing run, library pool, library prep kit, analysis version, task version, task, run, workflow, etc.

[0051] Service types can include genomic data services, workflow execution services, and the like.

[0052] Example 10 - Exemplary Platform In any of the examples herein, an infrastructure that provides policy-based sharing may be referred to as a "platform." Such a platform may be integrated into a multi-tenant cloud-based platform that provides access to multiple applications by tenants. As described herein, such a platform may become a virtual place where tenants can collaborate via the sharing functionality described herein.

[0053] The platform can be implemented as a software-as-a-service (SaaS) platform that orchestrates access to genomic digital data resources via the policy-based access control techniques described herein.

[0054] Various portions of functionality may be referred to as being inside or outside the platform, although either arrangement may be implemented. For example, some functionality may be delegated to other service providers or brought into the platform as desired. In some cases, functionality may be described as being in an authentication services platform that may be separate from or integrated into the overall multi-tenant cloud-based platform.

[0055] Example 11 - Exemplary System with Platform Implementing Policy-Based Sharing FIG. 3 is a block diagram of an exemplary system 300 including a platform 350 that implements policy-based genomic digital data sharing via signed access tokens 372.

[0056] Although the application is not shown, in reality the actual sharing functionality can be invoked by an application running on behalf of the tenant and requesting access to the genomic digital data 397 via the platform 350 and supporting software.

[0057] In this example, the owning tenant 310A controls access to the genomic digital data 397. Such control is achieved by configuring a policy document 360 (e.g., via an administration user interface). Configuration may include creating a custom role identifier 374 for inclusion in the policy document 360. Such configuration may be included as part of a publishing process if the tenant 310A wishes to publish the data 397 for sharing. Although not shown, publishing may also include the generation of a signed grant token as described herein.

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

[0059] Tenant 310B can then send access token 372 with role identifier 374 to the genomic digital data service, which provides access to genomic digital data 397 based on token 372.

[0060] Example 12 - Exemplary Method for Implementing Policy-Based Sharing FIG. 4 is a flowchart of an exemplary method 400 that implements policy-based genomic digital data sharing via signed access tokens and may be implemented, for example, by the system shown in FIG. 3 (e.g., by platform 350).

[0061] In any of the embodiments herein, in response to receiving an access request, a role identifier specified in a policy-based access control definition (e.g., a policy document) can be provided for the access request. The role identifier can then be included in a signed access token.

[0062] In this example, at 410, a policy configuration with a role identifier is received from a controlling (eg, owner or agent) tenant.

[0063] At 420, a request to access data controlled by the policy configuration is received from another tenant. As described herein, such a request may include a request for a token.

[0064] At 430, the request is granted based on a configured policy (e.g., a policy document configured by the controlling tenant). For example, based on the policy, a signed access token (e.g., having a role identifier) ​​can be provided at 440. At 450, the access request can be granted based on the signed access token (e.g., based on the presence of an appropriate scope for the role identifier).

[0065] Example 13 - Exemplary Tenant-in-Own In any of the examples herein, the term "owning tenant" can be used to express that policy-based sharing is essentially tenant-to-tenant based sharing. An owning tenant can grant access to genomic digital data to which the owning tenant already has access. By publishing data and configuring policy documents, other tenants can access the owning tenant's data.

[0066] In practice, the owning tenant may delegate a share of the operation to another tenant, who may then become a tenant for common purposes. Thus, the owning tenant may also be referred to as the "primary tenant."

[0067] Example 14 - Exemplary Access Request In any of the examples herein, the access request can take a variety of forms. For example, the access request can specify the genomic digital data desired to be shared (e.g., using an identifier). Alternatively, a general request can be submitted, providing a list of available resources and associated identifiers for selection. The access request can then be completed by providing the identifier of the specific resource desired.

[0068] In practice, the access request may be provided via communication between the application and a platform that provides policy-based shared services.

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

[0070] In a session-based system, an access request can be sent when a session begins (e.g., a user authenticates), and an access token can be generated based on the user identity. Applications created from the session can then access resources indicated by the roles in the access token.

[0071] Example 15 - Exemplary Invitation In any of the embodiments herein, an invitation process can be used to invite tenants for sharing. For example, a newly onboarded tenant can receive a particular invitation by default. Other tenants can receive an invitation when signing up for a particular application or service. For example, an application subscription model can provide access to the application (e.g., any shared associated public data as described herein) upon subscribing to the application. Other tenants can receive an invitation as part of being added to a policy document.

[0072] In practice, invitations may be controlled by a policy document or other resource that indicates when sharing is initiated.

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

[0074] Example 16 - Exemplary System for Generating Signed Access Tokens FIG. 5 is a block diagram of an example system 500 that generates a signed access token 572 based on an access request 520 and a policy document 560 .

[0075] In this example, a user identifier 505 for a given tenant is accessing an application 510 that requests access to the underlying genomic digital data 597 .

[0076] The access request 520 may include multiple attributes, and in an embodiment includes a user identification set 530 that includes a workgroup identifier 535 , a tenant identifier 537 , and an application identifier 540 .

[0077] A platform authentication service token generator (e.g., authentication service 140 of FIG. 1 or platform 350 of FIG. 3) receives access request 520 as input and generates signed access token 572 based on policy document 560. In this example, user identification set 530 and application identifier 540 support access, so token 572 includes role identifier 574 and tenant identifier 576 of the issue's tenant (e.g., the associated user is the user).

[0078] When provided with a signed access token 572, the genomic data service 590 can validate 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.

[0079] Further security can be provided via grant tokens as described herein.

[0080] Example 17 - Exemplary Method for Generating a Signed Access Token FIG. 6 is a flowchart of an example method 600 for generating a signed access token, which may be implemented, for example, by the system shown in FIG. 5 (eg, by token generator 550).

[0081] An access request is received from a user identity set at 610. In practice, an application used by a user having a user identity set may actually send a request on behalf of the user's user identity.

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

[0083] At 640, the signed access token with the role identifier is sent to the genomic data service.

[0084] Access to the genomic digital data can then be granted based on the role identifier.

[0085] Example 18 - Exemplary Applications 5, an application 510 can send an access request on behalf of a user identifier 505. In any of the examples herein, the request may be described as coming from a tenant or user identifier, but in reality, the application can act on behalf of such a tenant or user identifier. An application instance can be associated with an authenticated user identifier and / or tenant identifier used for security purposes (e.g., authenticating the request, determining the tenant identifier, determining the workgroup identifier, etc.).

[0086] Such applications can take a variety of forms and can be used to acquire, manage, and analyze genomic digital data as described herein.

[0087] Example 19 - Exemplary Supported Scenarios FIG. 7 is a visualization 700 of supported scenarios 710 that can be implemented via the techniques described herein.

[0088] Public access sharing 720 can be implemented as described herein by publishing genomic digital data that is, or is desired to be, public under a tenant identifier used to construct a policy document describing that data is available (e.g., to all users, all users of a given application, or some other criteria).

[0089] An example of public access sharing can be implemented with respect to an application. Thus, for example, tenants subscribing to a particular application can be granted access to a collection of public data in a format compatible with the application. In such a case, a policy document may be provided to all tenants (e.g., "tid: * :) can specify that requests from an application (e.g., "Application:Olympia") are granted access to the shared public data.

[0090] Inter-tenant sharing 730 can be implemented as described herein by publishing genomic digital data under a tenant identifier that configures a policy document that specifies the conditions governing sharing (e.g., other tenants can access the data). An invitation process can be involved, but other tenants do not need to configure role identifiers, as the controlling tenant can do so.

[0091] Workgroup-based sharing 740 can be implemented as described herein by publishing genomic digital data under a tenant identifier that configures a policy document that specifies the conditions governing sharing (e.g., one or more workgroups can access the data). An invitation process can be involved, but members of the workgroup do not need to configure role identifiers, as the controlling tenant can do so. Workgroups can be intra-tenant or inter-tenant (e.g., spanning multiple tenants).

[0092] Sharing 750 with external service providers can also be implemented as described herein, even if they are not operating in the capacity of the appropriate tenant, by creating a special tenant identifier for the external service provider. In this way, the external service provider can access genomic digital data on the platform, perform analyses thereon, and publish the results back to the platform for access by the tenant (e.g., that requested the external service provider perform the analysis).

[0093] Other scenarios are possible because policy documents can contain a rich set of conditions that allow sharing. Runtime policy document evaluation can be used, avoiding extensive reconfiguration of individual user roles by tenant operators.

[0094] Example 20 - Exemplary Workgroup In any of the embodiments herein, any number of users may be assigned to be members of a workgroup identified by a workgroup identifier within the platform. Such users may be in the same tenant or may span across tenants. Workgroup membership may be controlled by an administrator or by a programmatic process.

[0095] Example 21 - Exemplary Token Signature In any of the embodiments herein, the access token or grant token may be digitally signed by the controlling tenant for authentication purposes. In practice, a public-private key encryption approach may be used, where the token is signed with the tenant's private key and authenticated with the tenant's public key.

[0096] In practice, the platform operator's or agent's keys can be used in place of tenant keys to simplify operations: any keys that can be trusted and verified by the platform can be used to achieve the trust relationship that is enforced to prevent unauthorized sharing between tenants.

[0097] Example 22 - Exemplary Policy Document In any of the examples herein, policy documents can be used to control sharing. Such policy documents can therefore function as policy-based access control definitions. As described herein, policy-based access control definitions can be evaluated at the time an access request is received.

[0098] 8 is a block diagram of an example policy document 860 that can be used in any of the embodiments herein. In practice, policy document 860 is configured (e.g., created, read, updated, or deleted) by the tenant that controls the resource (e.g., genomic digital data) with which policy document 860 is associated in the platform. For example, an administration user interface can be provided for access by the tenant's operator user, or configuration can be programmable, if desired.

[0099] As described herein, policy document 860 can filter access requests based on application identifier or name, identity (e.g., tenant identifier, workgroup identifier, etc.), etc. Although not shown, policy document 860 can be linked (e.g., mapped) to role identifiers (e.g., controlled by constituent tenants), and thus policy document 860 achieves overall access control by acting as a gatekeeper to role identifiers, which may ultimately be used to authorize access to protected shareable resources.

[0100] Various formats can be used to achieve filtering. In this example, policy document 860 can include metadata 861 (e.g., date, version, etc.) and one or more statements 862. A statement can take the form of an effect, tenant identification parameters 863, and zero or more conditions 864. An effect can specify that the effect takes effect if any of identity parameters 863 and conditions 864 are met. Such an effect can be that sharing is permitted (e.g., "allowed"), or that a particular type of sharing is permitted (e.g., read-only, read-write, etc.), or that permissions as described herein are granted. However, the type of sharing can alternatively be achieved by creating different role identifiers with different levels of access.

[0101] In practice, identity 863 is listed separately to emphasize that tenant identification parameters are typically specified as part of policy document 860 and effectively function 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 the tenant identifier parameter, the parameter is considered satisfied, and if any condition 864 is also satisfied, the statement is executed.

[0102] As described herein, a given condition 864 can include filter parameters such as an application identifier, a workgroup identifier, an application role identifier, etc. Requests with attributes that satisfy the condition cause the statement to be executed (e.g., allow access). Thus, access to the underlying role can be filtered based on such attributes.

[0103] If the policy document is satisfied, the linked role identifier is included in the generated access token as described herein.

[0104] Additional functionality or configurations can be incorporated into policy document 860 as desired to extend sharing functionality. For example, policy document 860 can incorporate or reference trusted external resources, such as smart contracts as described herein.

[0105] Example 23 - Exemplary Signed Access Token In any of the embodiments herein, a shared access token can be generated based on a policy document and an incoming access request (e.g., via a role identifier) ​​that controls access to resources linked to the policy document.

[0106] 9 is a block diagram of an example signed access token 972 that may be used in any of the embodiments herein. In practice, the actual token 972 may take different forms, having more or fewer fields therein.

[0107] The subject 974 may be a system user identifier.

[0108] The issuer 976 may indicate which instance of the platform authentication system issued the token, or the issuer may be the controlling tenant.

[0109] Tenant identifier 978 may indicate the tenant identifier of the user (eg, the user associated with the application requesting the resource).

[0110] Membership can be encoded in the access token 972 based on the user's roles and permissions and if they meet policy criteria. During access token generation, a user identifier that meets the policy criteria automatically gets the associated role identifier as membership according to the policy set at the time of access grant. 980 can contain a list of members the user has access to. Membership can be indicated by role identifier 982 and / or workgroup identifier 984. A permission index (or "for all") can be used to indicate the role identifier. * "). For example, a user can have membership in both a role and a workgroup.

[0111] The access control list 990 can include a tenant identifier and a user identifier along with the granted permissions for the associated resource. The access control list in the token 972 can be included for efficiency purposes (e.g., so that a separate access control list does not have to be checked), or it can act as a double check on an access control list already in place (e.g., an access control list already shipped to the genomic data service as part of the grant token).

[0112] The grant type 992 may indicate the grant type or authentication flow for how the user obtained the token 972 .

[0113] The audience 994 can determine which cloud provider services a user is trying to access.

[0114] The service 996 may indicate the application or service that the user used to generate the token 972 .

[0115] The scope 998 may include a list of granted permissions (e.g., an identifier indicating the type of access allowed by specifying the service type, resource type, and permission type (e.g., "GDS.FILES.UPDATE", "GSS.LIBRARYPOOLS.READ", etc.)).

[0116] In practice, the signed access token 972 may be implemented as a JSON Web Token or other format that supports storage of relevant fields, may be signed with the signer's private key, and allows authentication via the signer's public key.

[0117] Example 24 - Exemplary Access Token Generation System FIG. 10 is a block diagram of an example system 1000 that generates an access token 1072 based on attributes of an access request 1020 and conditions of a policy document 1060 .

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

[0119] The policy document 1060 may include a role identifier 1074, which may not be explicitly stored in the document 1060, but may instead be linked (e.g., in a mapping between the role identifier and the policy document). The policy document 1060 may include multiple conditions 1064A-N, each including a pair of a filter attribute 1064A and a filter parameter 1066A. The filter attribute 1064A may specify an attribute by name or identifier, and the filter parameter 1066A may specify a parameter that indicates which attribute values ​​are eligible for assignment of the role identifier 1074. In practice, the parameter 1066A may take the form of a single value, a list, a wildcard, etc.

[0120] The access token generator 1050 can match policy parameters with attributes (e.g., of the received request). External conditions can also be included (e.g., conditions that are not part of the access request 1020).

[0121] If the access request 1020 qualifies for role assignment as indicated by the conditions 1064A-N, the role identifier 1074 may be included in the access token 1072 along with the tenant identifier (eg, the requesting user).

[0122] The token 1072 may be signed using a private key (e.g., of the controlling tenant or cloud service provider). Such signing may be achieved using conventional or other public-private key encryption methods and may be a function separate from the token generator 1050. If signed, the token 1072 may be authenticated using the signer's public key.

[0123] Example 25 - Exemplary Access Token Generation Method FIG. 11 is a flowchart of an example method 1100 for generating an access token based on attributes of an access request and conditions of a policy document, which may be implemented, for example, by the system 1000 of FIG. 10 (e.g., the access token generator 1050 described herein or other access token generation system).

[0124] At 1110, a request to access the shared genomic digital data is received, the request including one or more attributes. Such attributes may take the form of attribute name and attribute value pairs, although the attribute names may be implied (e.g., based on their position in the request, etc.).

[0125] At 1120, a policy document for the shared genomic digital data is accessed, the policy having one or more conditions.

[0126] 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 can be included if the attributes indicate that it satisfies the conditions of the request policy. External attributes can also be included to influence the generation of the token (e.g., whether the requester's tenant has an increased subscription level).

[0127] As described herein, the resulting token may be signed.

[0128] Example 26 - Exemplary Genomic Digital Data Publication System 12 is a block diagram of a system 1200 that exposes underlying data (e.g., genomic digital data) 1297 for policy-based sharing. In practice, system 1200 may be incorporated into any of the policy-based sharing examples herein and invoked to configure (e.g., set up) the sharing.

[0129] In this example, the controlling tenant 1210 has access to a workgroup administration console 1220 to provide access to the shared underlying data 1297 provided by the genomic data service 1290 .

[0130] An access control list 1292 can be created to enforce restrictions on data 1297. The access control list 1292 can include entries indicating a controlling 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.).

[0131] Tenant 1210 generates policy document 1260, role identifier 1236, and underlying data 1297 contained in policy store 1255 and linked (e.g., mapped) to tenant identifier 1210's tenant identifier.

[0132] In this example, the policy document 1260 specifies the version and all tenants (e.g., "TID: * "). A signed grant token 1230 is created that includes one or more access control lists dictated by the publishing scenario. In this way, the access control lists can be shipped to a genome data service 1290, which stores the access control lists for future reference (e.g., grants permissions based on requests associated with role id 1236). In this example, the tenant identifier 1234 of the controlling tenant and the role identifier 1236 created for the policy-based sharing scenario are included.

[0133] The illustrated scenario may also be referred to as "publishing" data (e.g., data 1297) because tenant 1210 has made the data available to those who are eligible (e.g., by those requests that meet the conditions in policy 1260).

[0134] Example 27 - Exemplary Genomic Digital Data Publishing Method 13 is a flowchart of an example method 1300 of publishing genomic content for policy-based sharing, which may be implemented, for example, by the system 1200 of FIG. 12 (e.g., the workgroup steering counsel 1220 or other portion of the platform that supports policy-based sharing as described herein). As described herein, the method 1300 may be driven by a tenant (e.g., a workgroup operator) granting access.

[0135] A custom role identifier (e.g., with a policy document linked to the role identifier) ​​is created at 1320. Such a role identifier may be unique within the platform and is assigned in response to a publication request.

[0136] A signed grant token is created with the list of access control lists at 1340. The grant token can be associated (e.g., linked) to a resource identifier that identifies the genome content, as described herein.

[0137] At 1360, the content is published to the genomic data service using the grant token. For example, the data can be uploaded to the genomic data service if it does not already exist. The grant token can be validated to control access to protected resources.

[0138] Example 28 - Exemplary Genomic Digital Data Access Method 14 is a flowchart of an exemplary method 1400 for accessing published shared genomic content, which may be implemented, for example, by any of the systems supporting policy-based sharing described herein. Such methods are typically driven by an enterprise user identifier accessing the resource.

[0139] At 1420, an access request is received (eg, by the platform from an access user identifier for a given access tenant).

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

[0141] At 1460, a genomic digital data resource is accessed with the signed access token. For example, a request can be sent to a genomic data service, which responds with data.

[0142] Example 29 - Exemplary External Service Provider Registration Method 15 is a flowchart of an example method 1500 for registering an external service provider, which may be implemented, for example, by any of the systems supporting policy-based sharing described herein. Such a method 1500 is typically driven by an administrative user identifier or process. As described herein, various external service provider scenarios may be supported.

[0143] At 1520, a registration of an external service provider with the platform is received (e.g., by the platform). Such registration may include a scope and grant of access and may be performed by an administrative user.

[0144] At 1540, a registration of the external service provider as a proxy tenant is received. The tenant identifier can be used for the proxy tenant even if the external service provider may not act in the capacity of a tenant or participate as a full tenant of the platform.

[0145] At 1560, policy-based access control is created (e.g., enabling inter-tenant sharing via roles created under the external service provider's proxy tenant). Policies can be associated with roles. In effect, the data is considered owned by the external service provider (via the proxy tenant identifier), and the data is shared with the access tenant via policy-based sharing as described herein.

[0146] A more detailed use case is provided in Figure 21 below.

[0147] Example 30 - Exemplary External Service Provider Integration Method 16 is a flowchart of an example method 1600 for integrating external service providers into a policy-based sharing platform, which may be implemented, for example, by any of the systems supporting policy-based sharing described herein. Such a method 1600 is typically driven by an access user identifier (e.g., from another tenant) or process.

[0148] At 1620, a workflow is initiated to communicate with an external service provider. Such a workflow may be kicked off to perform a task associated with the external service provider. For example, a tenant may wish to send a physical biosample and receive digital genomic data resulting from an analysis of the biosample, or the tenant may wish to have generated genomic digital data, such as sequencing results, and have the results interpreted by the external service provider.

[0149] A grant token is generated for the external service provider (e.g., for a particular sharing scenario) at 1640. In practice, the workflow execution service that executes the workflow may request the generation of a grant token.

[0150] At 1660, the external service provider is called with the grant token, which is verified (eg, using the administration public key).

[0151] At 1660, results (e.g., biosample analysis, data analysis, etc.) are received from the external service provider and accepted into the genomic data service (e.g., may be accessed by a user of the tenant that initiated the workflow that includes 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 or on behalf of the requesting tenant.

[0152] A more detailed use case and sample policy is provided in Figure 22 below.

[0153] Example 31 - Exemplary External Service Provider In any of the examples herein, the external service provider may be a service provider that provides genomic data services to tenants of the system. Thus, the tenant from which the policy-based access control definition is received may be a proxy tenant representing the external service provider for which policy-based sharing is implemented. Because the external service provider operates outside the system (e.g., not as a tenant of the system), a proxy tenant identifier may be configured for use by the external service provider, and the external service provider may register with the platform associated with the proxy tenant identifier. As described herein, the external service provider may utilize the policy-based inter-tenant sharing techniques described herein.

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

[0155] From the user's perspective, external service providers may appear as third-party applications, and their services are available to the user. In this way, a rich ecosystem of research can be provided in which third-party applications can be interfaced to the platform, so that the platform is not limited only to applications provided by the platform orchestrator or other tenants.

[0156] Example 32 - Exemplary Token Verification 17 is a block diagram of an example system 1700 for verifying (e.g., authenticating) a signed access token that may be implemented to achieve token authentication in any of the embodiments herein. In this example, a signed access token 1772 (having a role identifier 1774 and a tenant identifier 1776) is signed with the private key of a control tenant 1710. In practice, the private key of the control tenant may be managed by a tenant or operator (e.g., a platform orchestrator) of a cloud service provider.

[0157] Authenticator 1780 can accept the public keys of control tenant 1710 and signed token 1772 and output authentication result 1790 (e.g., whether token 1772 was indeed signed by the private key of control tenant 1710). Authenticator 1780 can take the form of conventional public-private key encryption algorithms (e.g., including hashing, etc.) to achieve validation of token 1772.

[0158] After verification, further processing can be performed to determine whether permissions are available for a given resource (e.g., based on membership in a role identifier, workgroup identifier, etc.) In response to determining that a member satisfies a specified condition (e.g., satisfies an access control list), the associated permissions (e.g., in the access control list) are granted to the requester associated with the token.

[0159] Although a signed access token 1772 is shown, the system 1700 may also be used for signed grant tokens as described herein.

[0160] Example 33 - Exemplary Genomic Data Implementation In any of the examples herein, the genomic data can be in the form of a genome file type. Such file types can be associated with different genomic data, distinguishing between data obtained during genome sequencing (e.g., raw data from a sequencing instrument, assembled genome, etc.), data for assistance during assembly (e.g., a reference genome), and data representing the results of comparative genomic analysis. Comparative genomic analysis can include comparisons between genomes (e.g., file types representing single nucleotide polymorphisms, insertions, deletions, structural variants, and copy number variations within a genome compared to a reference genome).

[0161] An example of such a file type is the VCF (SNP) file type. VCF stands for "Variant Call Format." It is a standardized text file format for representing variant calls for SNPs, INDELs, SVs, and CNVs. SNPs (Single Nucleotide Polymorphisms) are the most common type of genetic variation in people's genomes. Each SNP represents a difference in a single DNA building block (e.g., a nucleotide). In practice, this is the widely used VCF.

[0162] Another example of a file type is the VCF (INDEL) file type. INDEL is a molecular biology term for an insertion or deletion in DNA. The number of INDELs in the human genome is second only to the number of SNPs. INDELs can play an important role in genetics.

[0163] Another example is the VCF(SV) file type. SV (or Structural Variant) is a large DNA sequence that is inserted, inverted, deleted, or duplicated within a genome.

[0164] Another example is the VCF (CNV) file type. CNV (or Copy Number Variation) is when the number of copies of a particular gene changes from one individual to the next. Some cancers are thought to be associated with elevated copy numbers of certain genes.

[0165] Another example is the BAM file type. A Binary Alignment Map (BAM) can be the comprehensive raw data of a genome sequence. It can contain a losslessly compressed binary representation of the sequencing alignment map. BAM files tend to be around 90-100 gigabytes in size. They can be generated by aligning FASQ files to a reference genome. A BAM file (.bam) is the binary version of a SAM file. A SAM file (.sam) is a tab-delimited text file containing sequence alignment data.

[0166] Another example is the FASTQ file type, which contains billions of entries and is approximately 90-100 gigabytes in size, making it too large to open in a regular text editor. FASTQ files may be the final raw data.

[0167] Another example is a quality control metric file type (e.g., report). Before running any alignment or assembly, it is possible to check the quality of the underlying data. Quality can be checked from within the sequencing program. Quality control analysis can test a number of different metrics and produce a concatenated report. The report can include a simple classification (e.g., red, yellow, green) to indicate whether the result is poor, intermediate, or good.

[0168] Example 34 - Exemplary Special Permissions In any of the examples herein, special permissions in a genomic context can be implemented. For example, permission granularity can be extended to file types in policy statements. Thus, a policy can specify that different tenants, workgroups, users, or application roles can have different permissions for different genomic file types or different genomic file type categories (e.g., raw sequencing data, assembled genomes, reference genomes, comparative genomic analysis, etc.).

[0169] Special so-called "background" permissions can allow use of resources (e.g., file types) by applications or other infrastructure without granting read access (e.g., because they cannot be read directly). 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 genomics analyses without granting read access to the reference genome itself.

[0170] Additionally, special permissions can be specified for executable workflows. For example, a "high-level run-only" permission can allow high-level visibility of a workflow (e.g., steps, step progression, error messages, etc.) without revealing workflow details (e.g., the underlying interpreted code) or allowing workflow modification. Thus, workflows can be shared between tenants without revealing every small technical detail within them.

[0171] Example 35 - Exemplary Application Implementation In any of the examples herein, the application may be dedicated to facilitating genomics use cases, such as clinical genomics. For example, a cloud-based in vitro diagnostic solution for oncology may incorporate applications that support sample intake, wet-lab protocols (e.g., extraction, library preparation, indexing / pooling), sequencing, multiplexing, sequencing quality control, and then secondary analysis, ultimately resulting in a report. Secondary analysis may include comparative genomic analysis, such as detecting single-base variants.

[0172] Such applications can harmonize various services and unify the management of genomic data to enable efficient and accurate collection and analysis of genomic data. For example, a genomics laboratory service, a workflow service, an event notification service, a task service, and a genomics data store can work together under the orchestration of applications operating in the shared environment described herein.

[0173] Thus, different actors acting as tenants or external service providers can collaborate to share information using the policy-based genomic data sharing techniques described herein.

[0174] Example 36 - Exemplary Smart Contract Integration 18 is a block diagram illustrating the integration of smart contracts 1865 into a policy-based sharing platform that can be implemented to extend policy document functionality in any of the embodiments herein. A policy can point to a contract, such that anyone who fulfills the contract has access to the data via the policy. Conversely, a violation or failure to fulfill the contract means that a party does not have access to the data via the policy. A party can be designated as a tenant, workgroup, etc.

[0175] In this example, platform authentication service token generator 1850 consults policy 1860 to determine how to generate a signed access token 1872 with a role identifier 1874 and a tenant identifier 1876. As described herein, generation 1850 may also examine one or more attributes of the received request (e.g., tenant identifier, application identifier, etc.).

[0176] As shown, policy document 1860 can include or reference smart contract 1865. Smart contract 1865 can itself reference blockchain service 1897, which memorizes agreements of one or more tenants 1810A-N. Such agreements can be between tenants, between tenants and cloud service providers, between tenants and third parties, or some combination thereof. Such blockchain services can use blockchain technology, such as a consensus-based, immutable record of agreements (e.g., agreement existence, agreement level, service level, etc.), and can be built on blockchain infrastructure from any of a variety of providers or technologies (e.g., Ethereum-based functionality, etc.).

[0177] Trust relationships, such as between the platform and services, between tenants, etc., can be established through trust documents that can facilitate automated evolution of policy documents 1860 based on agreements expressed by services 1897.

[0178] In this way, any tenant that satisfies the terms of the contract has access to the data specified in the associated policy. Automated contract administration is then provided to facilitate immediate access to the data specified by the contract once the contract term (e.g., payment, subscription, or other term) has been satisfied.

[0179] Grant tokens can be generated based on the completion of a contract, and access tokens can be generated when access is requested in light of an associated policy.

[0180] As a further feature, access to data can be logged for subsequent auditing capabilities. 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 the access, and can themselves be annotated for compliance or legal reasons (e.g., "Agreement between Party X and Party Y dated December 15, 2017"), etc.

[0181] Example 37 - Exemplary Trust Document In any of the examples herein, the policy-based sharing platform can document trust relationships between tenants as trust documents. For example, the trust document can store a consent agreement for one tenant that reflects that trust has been established with another tenant (e.g., by storing the originating tenant, the destination tenant, the consent agreement date, and consent metadata).

[0182] Such trust documents can be enforced as a prerequisite for sharing data with tenants, e.g., in such a scenario, policies are only valid if supported by a trust document.

[0183] Example 38 - Exemplary Smart Contract Method FIG. 19 is a flowchart of an example method 1900 of implementing smart contracts within a policy-based sharing platform that may be implemented to extend policy document functionality in any of the examples herein.

[0184] At 1920, the tenancy agreement is reflected in a blockchain service (e.g., provided pursuant to Ethereum or other blockchain infrastructure).

[0185] At 1940, a request to access data controlled by one or more agreements is received. For example, a policy that references an agreement can be substituted for the data.

[0186] At 1960, a request to access the data is granted based on the policy with reference to the blockchain service.

[0187] At a later point in time, the blockchain service can be updated to reflect changes in the tenant agreement, such that requests may no longer be granted, may be newly granted, etc. In other words, changes to the agreement may result in changes in whether access is granted based on policies that reference the agreement.

[0188] Example 39 - Exemplary Public Use Case Figure 20 is a flow diagram of an example public use case 2000 that can be implemented in any of the examples herein. While this example shows "public_access," such use can cover both public and inter-tenant sharing, and can parallel the description of the methods in Figures 13 and 14.

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

[0190] Subsequent stages of searching for resources can be driven by a user identifier from another tenant 2020. The access token can include membership (e.g., a role identifier indicating the membership). Receiving access can take the form of receiving a list of resources from which a selection can be made for actual access.

[0191] Example 40 - Exemplary Grant Token In any of the embodiments herein, a grant token can associate a role identifier with a resource (e.g., a resource identifier), which serves as a policy identity that includes policies or rules for data access to the associated resource.

[0192] For example, the resource identifier may be included in the grant token associated with a table that maps the grant token to the resource identifier or is otherwise linked to the grant token.

[0193] Example 41 - Exemplary External Service Provider Use Case Figures 21 and 22 are flow diagrams of example external service provider use case methods 2100, 2200 that can be implemented in any of the examples herein. Such use cases can be paralleled with the method descriptions of Figures 15 and 16. Initially, the external service provider is registered (e.g., as a proxy tenant) and the external service provider is integrated into the system (e.g., policy-based sharing is used to enable the external service provider's access to the system, whether for read access, write access, or both).

[0194] In an external service provider scenario, a single policy can achieve sharing as described herein. Such a policy can be defined during the external service provider's registration with the platform. Such a policy can include information such as with which tenants the external service provider can share data. For example, in a scenario in which an external service provider uploads data, the policy can both allow the external service provider to upload data and allow the access tenant to access the data uploaded by the external service provider.

[0195] Data generated by external service providers can go to a dedicated tenant (e.g., "tenant_ESP"), and the platform operator can define the dedicated tenant's policy for sharing data with tenants who want to use external service provider sharing. When an access tenant generates an access token, the token is encoded with memberships based on their access rights, and the role identifier specified in the policy is dynamically entered as one of the memberships if the tenant meets the policy criteria.

[0196] Sharing scenarios can be used to support workflows involving external service providers. Typical workflows that can be initiated include an external service provider uploading genomic results from an analysis (e.g., of a physical biosample), an external service provider downloading genomic data and uploading the results of the analysis (e.g., download genomic data, externally analyze genomic data, upload analysis results), etc. For example, a tenant may want to use an external service provider to generate a variant report based on the output from a sequencing process (e.g., a sample file containing base calls and quality information for filtered reads, such as a FASTQ file). The tenant can run a workflow with the external service provider to upload the sample file to the external service provider. After uploading, the external service provider can run their processes and generate a variant file that the tenant then accesses.

[0197] The platform does not need to be aware of the internal workings of the external service provider. An input file can be submitted, the external service provider will generate an output file, and the output file will be shared with the original policy (e.g., rid:<>) under which the file was originally uploaded. In this example, the external service provider can both read and write to the resource (e.g., file storage).

[0198] The initial stage of registering an external service provider with the platform is shown in FIG. 21 and can be driven by a workgroup operator identifier or process. An operator user identifier 2110 can interact with the platform 2152 and the external service provider 2156. Workflow execution services 2153 and genomic data services 2154 can come into play at a later time (e.g., integration, access, or both). The operator user identifier 2110 can be for the operator of the platform, although if necessary, a tenant operator identifier can be given such authority (e.g., to register and integrate external service providers).

[0199] Subsequently, after registration, the integration of the external service provider 2156 can be provided as part of a workflow that includes the services of the external service provider 2156. In effect, the data is owned by the proxy tenant of the external service provider 2156 and can be shared with other tenants.

[0200] In this example, the platform operator user identifier 2110 registers the external service provider 2156 (eg, the scope and grant of the external service provider 2156) with the platform 2152.

[0201] The operator user identifier 2110 then registers the external service provider 2156 with the dedicated tenant (e.g., a proxy tenant such as "Tenant_ESP" for the external service provider 2156). In a data write scenario, the external service provider processes data that can be streamed to the dedicated tenant even if the external service provider is not a full tenant of the system.

[0202] The platform operator user identifier 2110 can then create policy-based access controls that enable inter-tenant data sharing. For example, a proxy tenant can share data with one or more designated tenants.

[0203] An example policy that allows an external service provider ("Tenant_ESP") to share its data with Tenant1 is as follows: rid:<tenantESP_tenant1_GUID> (Example: Data owned by Tenant_ESP but shared with tenant1 with restricted permissions: GDS.FILES.READ) { “Version”:“1558387292”, “Statement”:[ “Effect”:“allow”, “scope”:“GDS.FILES.READ” “Identity”:{tid:tenant1} ] }

[0204] The policy is associated with the role identifier "tenantESP_tenant1_GUID".

[0205] An example policy that allows an external service provider (tenant_ESP) to share data with Tenant1_Clinical_Workgroup is as follows: rid:<tenantESP_tenant1_GUID> (Example: Data owned by Tenant_ESP but shared with tenant1 with restricted permissions: GDS.FILES.READ) { “Version”:“1558387292”, “Statement”:[ “Effect”:“allow”, “scope”:“GDS.FILES.READ” “Identity”:{wid:tenant1_clinical_workgroup1} ] }

[0206] The policy is associated with the role identifier "tenantESP_tenant1_GUID".

[0207] After registration is complete, integration can be implemented as shown in FIG. 22 , involving the same party and a user identifier 2220 from an access tenant (e.g., Tenant1) that wishes to utilize services provided by an external service provider 2256. In example method 2200, the user identifier 2220 from the access tenant initiates a workflow execution task (e.g., communicating with external service provider 2256) using workflow execution service 2253. For example, the task can be titled "Perform Interpretation." In this example, external service provider 2256 provides results to the access tenant, and providing the results includes uploading the results to genomic data service 2254, where the access tenant can access them.

[0208] The workflow execution service 2253 sends a request to generate a grant token for the external service provider 2256 using the proxy tenant identifier (e.g., "Tenant_ESP"). The token includes an access control list for each policy. The platform 2252 responds with a grant token, which can take the following general form: issuer=platform audience=esp access control list=[rid:<>] tenant id=tenant1 membership={}

[0209] The workflow can then call the external service provider 2256 with the grant token, which can be verified by the external service provider 2256 (the token's intended audience) using the public key of the platform orchestrator or other entity authorized to perform the registration.

[0210] The external service provider 2256 can then send a request to the platform 2252 to generate an access token for the genomic data service 2254 and copy the access control list from the access control list request in the grant token. The platform 2252 responds with an access token, which can take the following general form: issuer=platform audience=gds access control list=[rid:<>] membership={“rid”:<>} tenant id=tenant_ESP

[0211] The external service provider 2256 can then use the access token to upload the results to the genome data service 2254, which can be validated by the genome data service 2254 (the token's intended audience).

[0212] The uploaded data is then available to other tenants if the user id has the appropriate membership enabled via policy by the operator user of the other tenant (e.g., rid:<tenantESP_tenant1_GUID> ), user id2220 of the access tenant (tenant1), or any other user of the access tenant.

[0213] An example policy that allows all users in the access tenant (tenant1) to view processed data from external service providers is as follows: rid:<tenant1_ESP_data_read_access_GUID> { “Version”:“1558387292”, “Statement”:[ “Effect”:“allow”, “scope”:“GDS.FILES.READ” “Identity”:{uid: *} ] }

[0214] The policy is associated with the role identifier "tenant1_ESP_data_read_access_GUID".

[0215] Thus, access to data uploaded by external service providers is achieved by using the inter-tenant policy-based sharing techniques described herein, where the external service provider is assigned a proxy tenant identifier.

[0216] Thus, the creator of a policy with permission rights to resources can allow access to any internal or external tenant for a list of identities and resources.

[0217] Example 42 - Exemplary Policy Version Field In any of the examples herein, the version field of the policy can be used to facilitate audit tracking and to roll back the policy to a previous version.

[0218] Example 43 - Exemplary Policy In any of the examples herein, policies can be used to control sharing. Different policies can be used to achieve different sharing objectives. In the following examples, the platform orchestrator "Illumina" maintains a platform that supports a variety of policy-based sharing scenarios.

[0219] A policy can be associated with a role identifier that ultimately controls access to a shared resource. A policy can include one or more identities (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 an identity to enable access to the resource.

[0220] For example, the following policy can achieve application-enabled content, allowing users using a particular application ("Olympia") to access the content: rid:<illumina_app_enabled_data> (Owned by Illumina) { “Version”:“1558387292”, “Statement”:[ “Effect”:“allow”, “scope”:“GDS.FILES.READ,GDS.FOLDERS.READ,GDS.FOLDERS.WRITE” “Identity”:{tid: *} "Condition":{ “filter”:{“appid”:“olympia”}, “filetypes”:[“sam”,“vcf”,“bam”] } ] }

[0221] A policy achieves application-enabled content by including a filter that specifies the application identifier for the application in question. Another filter restricts access to certain file types specified in a file type filter (e.g., sam, vcf, bam). As shown, the policy is associated with the role identifier "illumina_app_enabled_data."

[0222] In another example, a policy may allow public content to be shared with anonymous users using a particular application. rid:<illumina_public_data> (Owned by Illumina) { “Version”:“1558387292”, “Statement”:[ “Effect”:“allow”, “scope”:“GDS.FILES.READ” “Identity”:{tid: *} "Condition":{ “filter”:{“appid”:“olympia”} } ] }

[0223] The policy achieves read-only sharing with any user by specifying a read-only scope and including a wildcard in the tenant identifier. In this example, access is restricted to users using the application ("olympia") specified in the policy's application identifier filter. However, removing the application filter in the policy allows read-only access by any user. As shown, the policy is associated with the role identifier "illumina_public_data."

[0224] In another example, private content is shared with labs (workgroups) lab001 and lab002. rid:<illumina_private_shared_data> (Owned by Illumina) { “Version”:“1558387292”, “Statement”:[ “Effect”:“allow”, “scope”:“GDS.FILES.READ” “Identity”:{wid:lab001,wid:lab002} ] }

[0225] The policy specifies a read-only scope and includes an explicit list of one or more workgroups to achieve read-only sharing with any user in the two workgroups. As shown, the policy is associated with the role identifier "illumina_private_shared_data."

[0226] In another example, Tenant User 1 shares data with Tenant 2 user with user identifier "2." rid:<tenant1_private_shared_data> (Owned by Tenant1 user-uid:1) { “Version”:“1558387292”, “Statement”:[ “Effect”:“allow”, “scope”:“GDS.FILES.READ” “Identity”:{uid:2} ] }

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

[0228] In another example, a workgroup for tenant1 shares data with users for tenant2 who have limited permissions (i.e., only read files and write files). rid:<tenant1_workgroup1_private_shared_data> (Owned by the workgroup owner of Tenant1) { “Version”:“1558387292”, “Statement”:[ “Effect”:“allow”, “scope”:“GDS.FILES.READ,GDS.FILES.WRITE” “Identity”:{uid:2} ] }

[0229] In this example, the policy is associated with the role identifier "tenant1_workgroup1_private_shared_data".

[0230] In yet another example, a workgroup for tenant1 shares data with another workgroup for tenant2. rid:<tenant1_workgroup1_private_shared_data> (Owned by the workgroup owner of Tenant1) { “Version”:“1558387292”, “Statement”:[ “Effect”:“allow”, “scope”:“GDS.FILES.READ,GDS.FILES.WRITE” “Identity”:{uid:2,wid:lab002} ] }

[0231] In this example, the policy is associated with the role identifier "tenant1_workgroup1_private_shared_data," which is reused from the previous example. Thus, more than one policy can be associated with a role identifier, allowing for stacked policies that can be used to effectively extend access (e.g., policies can be reused across role identifiers to grant similar users access to different resources).

[0232] As shown, different policies can support different sharing scenarios.

[0233] Example 44 - Exemplary Security Context In any of the embodiments herein, a role identifier (eg, role ID, rid, etc.) may alternatively be implemented as a security context identifier (eg, context ID, cid, etc.).

[0234] Example 45 - Exemplary Coordinating Parties In any of the embodiments herein, parties may collaborate on the platform by sharing genomic digital data. As described herein, such parties may be workgroups, tenants, or both. Collaborating workgroups may be intra-tenant workgroups (e.g., one tenant) or inter-tenant workgroups (e.g., one or more workgroups of a tenant collaborate with one or more workgroups of another tenant). Parties may include patients, laboratories, clinical laboratories (e.g., Quest Diagnostics, LabCorp, etc.), contract laboratories, medical clinicians, hospitals, universities, experts, counselors (e.g., genetic counselors), 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.

[0235] Example 46 - Example Use Case The technology described herein can be used in any of a wide variety of scenarios implemented in genomic information processing environments and platforms. For example, the technology can support primary, secondary, and tertiary analysis workflows within or across collaborating parties. In addition to intra-analysis collaboration, cross-analysis collaboration can also be supported, whereby a feedback loop of tertiary analysis results can be provided back to the party performing the secondary analysis for recalculation of the secondary analysis based on the tertiary analysis results. The technology described herein can also be used to enforce research-use-only restrictions or to restrict use for diagnostic purposes beyond approved clinical uses. Furthermore, the technology 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.).

[0236] Collaboration and sharing can be facilitated by policy-based access control of genomic digital data in any of the various workflows that support the above as described herein. For example, tenants can collaborate on workflows, and workflow results can be passed from one tenant to another.

[0237] Example 47 - Exemplary Use Cases: Primary, Secondary, and Tertiary Analysis Sequencing generates large amounts of genomic digital data, and the analytical process associated with such data can be complex. Various analytical tools can be used to reveal meaningful information in the data in a timely manner. The technology described herein can enable collaboration between analytical tools and associated workflows during use, and can provide the results of one workflow from one user to another. One way to describe the genomic digital data analysis process is to divide it into three main stages: primary, secondary, and tertiary data analysis. Some actions can be performed automatically by the sequencing device, while other actions occur after sequencing is complete.

[0238] Primary data analysis may include analysis performed during cycles of sequencing chemistry and imaging that provides base calls and associated quality scores representing the primary structure of nucleotide chains. In one example, the output of primary data analysis is a BCL base call file that indicates base calls for clusters of nucleotide chains. In practice, such analysis may be performed automatically on a sequencing system. The results of the primary analysis may take the form of genomic digital data embodied in a file and uploaded to the cloud for further processing during secondary analysis. Collaboration and sharing may be facilitated by policy-based access control of genomic digital data as described herein. For example, one tenant may perform the primary analysis and provide access to the results to one or more tenants for secondary analysis.

[0239] Secondary analysis can take the results of the primary analysis, which represent base calls of unaligned nucleotide fragments, and analyze and align the base calls of the nucleotide fragments of a sample to provide a determination of the complete sequence or sequence coverage (e.g., gene), from which genetic variants can be determined. For example, the output of the secondary analysis can be in the form of a FASTQ file containing sequence information and quality scores. Such analysis typically involves aligning and assembling nucleotide fragments. Given the complete sequence or sequence coverage, variants can be determined. Sequence alignment, variant calling, data visualization, RNA sequencing experiments, gene fusion detection, total RNA expression profiling, and determination of methylated bases can also be performed. Collaboration and sharing of genomic data during secondary analysis can be facilitated by policy-based access control of genomic digital data as described herein. For example, one tenant can perform the secondary analysis and provide access to the results to one or more tenants for tertiary analysis.

[0240] Tertiary data analysis can involve using any of a wide variety of biological data mining and interpretation tools on sequencing data to convert the data into knowledge. For example, variant interpretation and diagnosis can be performed on the results of secondary analysis. Collaboration and sharing of genomic data during tertiary analysis can be facilitated by policy-based access control of genomic digital data as described herein. For example, tertiary data analysis can include a recommendation regarding whether genomic data indicate that a patient will respond to a particular medical therapy (e.g., medication, radiation, etc.).

[0241] Example 48 - Exemplary Use Case: Intra-Analysis Collaboration In any of the embodiments herein, the policy-based access control techniques can be used for intra-analysis collaboration, where multiple parties (e.g., tenants, workgroups, or both) collaborate to perform intra-phase analysis.

[0242] Example 49 - Exemplary Use Case: Cross-Analysis Collaboration In any of the embodiments herein, the policy-based access control techniques can be used for intra-analysis collaboration, where one or more parties (e.g., tenants, workgroups, or both) perform an analysis, which is then provided to one or more other parties to perform subsequent analyses at different phases.

[0243] In such cases, a feedback loop of the tertiary analysis results may be provided back to the party that performed the secondary analysis for review against a re-run of the secondary analysis, and the secondary analysis results may then be updated so that the tertiary analysis can be reviewed or re-run (e.g., by the same or one or more other parties).

[0244] Example 50 - Exemplary Use Case: Government Agency Approval Equipment and Testing In any of the embodiments herein, policy-based access control techniques can be used to implement diagnostic processing across tenants for agency-approved diagnostic devices and / or tests, such as FDA-approved devices and / or tests, in scenarios where multiple tenants are involved and share data as part of the test.

[0245] Example 51 - Exemplary Use Case: Research Processing The access controls described herein can enforce research use-only processing. For example, research use-only processing can be performed by tenants or workgroups within tenants collaborating across institutional and geographic boundaries in genomic digital data sharing scenarios while preserving the security of the data. For example, access to individual patient identifiers can be restricted so that processing of the data cannot be correlated to a specific individual.

[0246] Example 52 - Illustrative Use Case: Privacy and Data Residency Additionally, access controls can be implemented to ensure compliance with privacy and / or health data residency (e.g., geographic location) requirements. For example, in a research scenario, individual health data that directly identifies information can be blocked or restricted, and aggregated health datasets with identity information can be published or pushed to third-party providers or other tenants for analysis.

[0247] In diagnostic scenarios, individual health data may be allowed to directly identify information.

[0248] 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 due to the conclusion of a process or by patient command.

[0249] For example, an access token can be used to verify that data resides in a particular geographic location or region.

[0250] Example 53 - Exemplary Benefits Policy-based sharing techniques can provide many advantages. For example, the ease with which sharing can be achieved in a policy-based sharing environment can encourage inter-tenant sharing in general. Due to the late-binding nature of role identifiers, there is no need to store a comprehensive mapping of users or tenants to roles. Instead, roles can be bound at runtime. Thus, the overall storage requirements for security data are reduced.

[0251] Similarly, the flexibility of policy-based role assignment allows for the incorporation of new standards without the need to redesign the platform or complicate operations for tenants.

[0252] Runtime role binding also provides more accurate role assignment: for example, changes in tenant status or service levels can be reflected immediately rather than after a period of time when pre-mapped roles are reassigned.

[0253] Another advantage is that executable workflows can be shared along with the underlying data on which such workflows are executed. Thus, tenants can share underlying data, execute shared workflows on such underlying data, and receive analytical results. Workflows can even invoke external service providers, leading to comprehensive collaboration scenarios that would not be possible without such technology.

[0254] The trust relationship can be enforced via signed tokens, as described herein. Thus, the security of the underlying data can be ensured, and cross-tenant sharing can be enabled while preserving the security of the underlying data. Auditing of access can also be achieved, and the audit log can be used for testing, security, or compliance purposes.

[0255] Software testing can also be more easily accomplished by easily setting up test tenants and sharing data with the test tenants, providing proof of concept and quality assurance testing for sharing scenarios that can then be extended outside of the test scenarios to real tenants.

[0256] Example 54 - Exemplary Computing System 23 illustrates an example of a suitable computing system 2300 capable of implementing digital aspects of the described innovation. The computing system 2300 is not intended to suggest any limitation as to the scope of use or functionality of the present disclosure, as the innovation can be implemented in a variety of computing systems.

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

[0258] In a multi-processing system, multiple processing units execute computer-executable instructions to increase processing power. The tangible memory 2320, 2325 can be volatile memory (e.g., registers, cache, RAM), non-volatile memory (e.g., ROM, EEPROM, flash memory, etc.), or some combination of the two accessible by the processing units 2310, 2315. The memory 2320, 2325 stores software 2380 that implements one or more innovations described herein in the form of computer-executable instructions suitable for execution by the processing units 2310, 2315.

[0259] The functionality may also be implemented, at least in part, by one or more hardware logic components, such as a Field Programmable Gate Array (FPGA), an Application-Specific Standard Product (ASSP), a System-on-a-Chip (SOC), a Complex Programmable Logic Device (CPLD), etc.

[0260] Computing system 2300 may have additional features. For example, computing system 2300 includes storage 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 interacting with a user. An interconnection mechanism (not shown), such as a bus, controller, or network, interconnects the components of computing system 2300. Typically, operating system software (not shown) provides an operating environment for other software executing within computing system 2300 and coordinates the activities of the components of computing system 2300.

[0261] Tangible storage 2340 may be removable or non-removable and include magnetic disks, magnetic tapes or cassettes, CD-ROMs, DVDs, or any other medium that can be used to store information in a non-transitory manner that can be accessed within computing system 2300. Storage 2340 stores instructions for software 2380 that implement one or more of the innovations described herein.

[0262] The input device(s) 2350 may be an input device such as a keyboard, a mouse, a pen, or a trackball, a voice input device, a scanning device, a touch device (e.g., a touchpad, a display, etc.), or another device that provides input to the computing system 2300. The output device(s) 2360 may be a display, a printer, speakers, a CD writer, or another device that provides output from the computing system 2300.

[0263] The communications connection(s) 2370 enable communication over a communications medium to another computing entity. The communications medium conveys information such as computer-executable instructions, audio or video input or output, or other data in a modulated data signal. A modulated data signal is a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communications media may use electrical, optical, RF, or other carriers.

[0264] The innovations may be described in the context of computer-executable instructions, such as those contained in program modules, executed in a computing system on a target real or virtual processor (e.g., ultimately executed on one or more hardware processors). Generally, program modules or components include routines, programs, libraries, objects, classes, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The functionality of the program modules may be combined or split between program modules as desired in various embodiments. The computer-executable instructions of the program modules may be executed in a local or distributed computing system.

[0265] For purposes of presentation, the detailed description uses terms such as "determine" and "use" to describe computer operations in a computing system. These terms are high-level descriptions of computer-performed operations and should not be confused with human-performed acts. The actual computer operations corresponding to these terms will vary depending on the implementation.

[0266] Example 55 - Computer-Readable Medium Any of the computer-readable media herein may be non-transitory (e.g., volatile memory such as DRAM or SRAM, non-volatile memory such as magnetic storage, optical storage, etc.) and / or tangible. Any of the storage actions described herein can be implemented by storing on 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) can be stored on one or more computer-readable media (e.g., computer-readable storage media or other tangible media). Computer-readable media may be limited to implementations that do not consist of signals.

[0267] Any of the methods described herein can be implemented by computer-executable instructions on 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, optical storage, etc.). Such instructions can cause a computing system to perform the method. The techniques described herein can be implemented in a variety of programming languages.

[0268] Example 56 - Exemplary Cloud Computing Environment 24 shows an exemplary cloud computing environment 2400 in which the described techniques can be implemented, including, for example, system 100 of FIG. 1 and other systems herein. Cloud computing environment 2400 includes a cloud computing service 2410. Cloud computing service 2410 can include various types of cloud computing resources, such as computer servers, data storage repositories, network resources, etc. Cloud computing service 2410 can be centrally located (e.g., provided by a data center of a business or organization) or distributed (e.g., provided by different data centers and / or various computing resources located in different locations, such as different cities or countries).

[0269] 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, the computing devices (e.g., 2420, 2422, and 2424) may be computers (e.g., desktop or laptop computers), mobile devices (e.g., tablet computers or smartphones), or other types of computing devices. For example, the computing devices (e.g., 2420, 2422, and 2424) may utilize cloud computing service 2410 to perform computing operations (e.g., data processing, data storage, etc.).

[0270] In practice, cloud-based, on-premise-based, or hybrid scenarios can be supported.

[0271] Example 57 - Exemplary Implementation Although some acts of the disclosed methods are described in a particular sequential order for convenience of presentation, such methods of description encompass rearrangement unless a particular order is required by specific language set forth herein. For example, acts described as sequential may, in some cases, be rearranged or performed simultaneously.

[0272] Example 58 - Exemplary Embodiment Any of the following embodiments can be implemented.

[0273] Clause 1. A method comprising: A software-as-a-service platform for orchestrating access to genomic digital data resources via policy-based access control, comprising: a computing system having a plurality of tenants seeking access to genomic digital data resources provided by one or more genomic data services; receiving a policy-based access control definition of a first one of the tenants for a given genomic digital data resource; 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; and and granting access to the given genomic digital data resource based on the policy-based access control definition for a second one of the tenants. Article 2. access to a given genomic digital data resource is controlled by a role identifier linked to a policy-based access control definition; The method is 10. The method of claim 1, further comprising, in response to the access request, providing a role identifier specified in the policy-based access control definition for the access request. Article 3. 3. The method of clause 2, wherein assigning a role identifier includes late binding the role identifier to a user identifier or tenant identifier of the access request. Article 4. generating a signed access token containing the role identifier in response to the access request; 4. The method of any one of clauses 2 or 3, wherein access is granted based on the presence of a role identifier in the signed access token. Article 5. The method of clause 4, wherein access is further granted based on verification of the signed access token. Article 6. publishing a signed grant token that includes the role identifier and the tenant identifier of the role operator of the role identifier; 6. The method of any one of clauses 4 or 5, wherein access is further granted based on whether the tenant identifier of the signed grant token has sufficient rights to grant the specified resource with respect to the role identifier. Clause 7. The method of any one of clauses 1-6, wherein a first one of the tenants includes a proxy tenant representing an external service provider for which policy-based sharing is implemented. Clause 8. The method of any one of clauses 1 to 7, wherein the policy-based access control definition includes a reference to a smart contract. Clause 9. The method of any one of clauses 1 to 8, wherein the policy-based access control definition includes a reference to a service level of a second one of the tenants, and access is granted according to the service level of the second one of the tenants as determined at the time of the request. Clause 10. The method of 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. Clause 11. The method of clause 10, wherein the filter parameter specifies a wildcard for the filter attribute. Clause 12. The method of clause 10 or 11, wherein the filter attribute includes an application. Clause 13. The method of any one of clauses 10 to 12, wherein the filter attribute includes an application role identifier. Clause 14. The method of any one of clauses 1 to 13, wherein the policy-based access control definition supports access control statements that specify an access outcome, a tenant identifier, and one or more conditions under which access is granted. Clause 15. The method of any one of clauses 1 to 14, wherein the policy-based access control definition supports public access, private access, and application-based access. Clause 16. The method of any one of clauses 1 to 15, wherein the policy-based access control definition includes parameters that are evaluated at runtime. Article 17. the parameters of the policy-based access control definition include an application identifier parameter; 17. The method of clause 16, wherein granting access includes comparing an application identifier parameter of the policy-based access control definition with an application identifier specified by a second one of the tenants seeking access to the genomic digital data resource. Article 18. The parameters of the policy-based access control definition include a tenant identifier parameter; 18. The method of any one of clauses 16 or 17, wherein granting access includes comparing a tenant identifier parameter of the access control definition with a tenant identifier of a second tenant seeking access to the genomic digital data resource. Clause 19. A multi-tenant cloud-based system, one or more processors; a memory coupled to the one or more processors; a policy store containing policy-based access control definitions received for the first tenant and including role identifiers; a genomic digital data resource linked to the role identifier; The memory includes computer-executable instructions that cause one or more processors to perform operations, the operations including: receiving a request to access the genomic digital data resource from a second tenant seeking access to the genomic digital data resource; and and granting access to the genomic digital data resource for the second tenant according to a policy-based access control definition that is evaluated at the time of the access request. Clause 20. One or more computer-readable media, computer-executable instructions for causing a computing system to receive a publication request for providing access to genomic digital data for a first tenant, wherein access to the genomic digital data is controlled by a role identifier linked to a policy document, the policy document including one or more conditions; computer-executable instructions that cause a computing system to receive a request for access to genomic digital data from a second tenant, the request for access being controlled by a role identifier linked to a policy document, the request including one or more attributes; computer-executable instructions for causing the computing system to access the policy document in response to an access request from the second tenant; A computer-readable medium comprising: computer-executable instructions that cause a computing system to generate an access token based on one or more attributes and one or more conditions, wherein in response to determining that the one or more conditions are satisfied by the one or more attributes, a role identifier is included in the access token, and the access token authorizes access to the genomic digital data via the role identifier. Clause 21. One or more computer-readable media containing computer-executable instructions that, when executed by a computing system, cause the computing system to perform the method of any one of clauses 1-18.

[0274] Example 58 - Illustrative Alternatives Techniques from any example can be combined with techniques described in any one or more of the other examples. Given the many possible embodiments to which the principles of the disclosed technology can be applied, it should be recognized that the illustrated embodiments are examples of the disclosed technology and should not be construed as limiting the scope of the disclosed technology. Rather, the scope of the disclosed technology includes what is encompassed by the scope and spirit of the following claims.

Claims

1. 1. A method comprising: In a computing system, a software-as-a-service platform provides access to genomic digital data resources provided by one or more genomic data services; orchestrating multi-tenant access to said genomic digital data resource via policy-based access control; receiving a policy-based access control definition of a first one of the tenants for a given genomic digital data resource; receiving a request to access the given genomic digital data resource from a second one of the tenants seeking access to the given genomic digital data resource; the genomic digital data resource includes genomic data obtained from a sequencing device, and the policy-based access control definition supports access control statements that specify one or more conditions under which access is granted; the access request includes one or more attributes; The method further comprises: accessing the policy-based access control definition in response to the access request from the second tenant; 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; granting the second one of the tenants access to the given genomic digital data resource based on the policy-based access control definition; A method comprising:

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

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

4. generating a signed access token in response to the access request, the signed access token including the role identifier; The method of claim 2 or 3, wherein access is granted based on the presence of the role identifier in the signed access token.

5. publishing a signed grant token that includes the role identifier and a tenant identifier of a role operator of the role identifier; The method of claim 4 , wherein access is further granted based on whether the tenant identifier of the signed grant token has sufficient rights to grant the specified resource with respect to the role identifier.

6. The method of any one of claims 1 to 5, wherein the first one of the tenants comprises a proxy tenant representing an external service provider for which policy-based sharing is implemented.

7. The method of any one of claims 1 to 6, wherein the policy-based access control definition specifies one or more access control statements including filter attributes and filter parameters.

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

9. The method of claim 7 or 8, wherein the filter attribute comprises an application.

10. The method of any one of claims 7 to 9, wherein the filter attribute comprises an application role identifier.

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

12. 1. A multi-tenant cloud-based system, comprising: one or more processors; a memory coupled to the one or more processors; a policy store containing the policy-based access control definitions received for the first tenant, a role identifier, and one or more conditions; a genomic digital data resource linked to the role identifier; the genomic digital data resource includes genomic data originating from a sequencing instrument; The memory includes computer-executable instructions that cause the one or more processors to perform operations, the 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, the request including one or more attributes; accessing the policy-based access control definition in response to the access request from the second tenant for access; 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 conditions are satisfied by the one or more attributes, adding the role identifier to the access token; and and granting the second tenant access to the genomic digital data resource in accordance with the policy-based access control definitions that are evaluated at the time of the access request.

Images