These are the official repositories for version 2 of the specification and the Reference Implementation:
An implementation of a Beacon (e.g., the V1.1 ELIXIR reference implementation) must implement the Global Alliance for Genomics and Health (GA4GH) Beacon standard as defined here. This standard has been through the GA4GH approval process, which means the standard must be approved by both the Regulatory and Ethics, and Data Security foundational workstreams.
The Beacon uses a 3-tiered access model - anonymous, registered, and controlled access. A Beacon that supports anonymous access responds to queries irrespective of the source of the query. For a Beacon to respond to a query at the registered tier, the user must identify themselves to the Beacon, for example by using an ELIXIR identity. For a Beacon to respond to a controlled access query, the user must have applied for, and been granted access to, the Beacon (or data derived from one or more individuals within the Beacon) before sending the query. Note that a Beacon may contain datasets (or collections of individuals) whose data is only accessible at specified tiers within the Beacon. This tiered access model allows the owner or controller of a Beacon to determine which responses are returned to whom depending on the query and the user who is making the request, for example to ensure the response respects the consent under which the data were collected. The ELIXIR Beacon network supports Beacons which respond at different tiers, for example only Beacons which have a response to anonymous queries need respond to an anonymous request. As part of the ELIXIR 2019-21 Beacon Network Implementation Study deliverable D3.3 a document has been written to describe security best practice for users interested in deploying or running a Beacon or users who govern data hosted within a Beacon, and the requirements for adding the Beacon to the ELIXIR Beacon network. As the Beacon standard extends in V2 towards supporting phenotype and range queries, the tiered access model becomes more important to ensure the Beacon response is appropriate to the underlying data.
As a Beacon is designed to support data discoverability of controlled access datasets, it is recommended that synthetic or artificial data is used for testing and initial deployment of Beacon instances. The use of synthetic data for testing is important in that it ensures that the full functionality of a Beacon can be tested and / or demonstrated without risk of exposing data from individuals. In addition to testing or demonstrating a deployment, synthetic data should be used for development, for example adding new features. Additionally, these data can also be used to demonstrate the access levels and data governance procedures for loading data to a Beacon to build trust with data controllers or data access committees who may be considering loading data to a Beacon. An example dataset that contains chromosome specific vcf files is hosted at EGA under dataset accession EGAD00001006673. While this dataset requires a user to log in to get access, the EGA test user can access this dataset.
Below are the latest news about Beacon v2
Instead of querying for a specific genomic variant (e.g. an A instead of a G at position 7577121 on chromosome 17), Beacons could also employ a “range match” concept, in which all or type specific variants mapping to a genomic interval are being identified.
@mbaudis 2018-11-16: more ...
While the Beacon response should be restricted to aggregate data (yes/no, counts, frequencies …), the usage of the protocol could be greatly expanded by providing an access method to data elements matched by a Beacon query.
As part of the mid-term product strategy, the ELIXIR Beacon team is evaluating the use of a “handover” protocol, in which rich data content (e.g. variant data, phenotypic information, low-level sequencing results) can be provided from linked services, initiated through a Beacon query (and possibly additional steps like protocol selection, authentication…). A discussion of the topic can e.g. be found in the Beacon developer area on Github (issue #114).
As of 2018-11-13, the handover concept has become part of the ongoing code development.
@mbaudis 2018-10-18: more ...
The Beacon Team wishes everybody a happy and healthy 2021! We’re excited about our upcoming Beacon v2, expected to be finalized later this year.
@mbaudis | @laurenfromont 2021-01-15: more ...
The coordinate system that should be used throughout GA4GH standards is 0-based half open.
@mbaudis 2019-03-14: more ...
In the original Beacon roadmap definitions, “clinical Beacon” (lower case) described a set of use cases instead of a specific Beacon flavour.
2020-03-23: more ...
Future Beacon API versions will support querying for additional, non-sequence related data types.
@mbaudis 2018-10-18: more ...
An v2 extension of the Beacon protocol will allow the query for additional
data beyond genome variants, using a proposed filters extension. Such filters
are thought to be prefixed attributes, where the (public or private) prefix
becomes the basis of scoping the value to the correct database value.
@tb143 | @mbaudis 2020-05-12: more ...