In the original Beacon roadmap definitions, “clinical Beacon” (lower case) described a set of use cases instead of a specific Beacon flavour.
Besides non-aggregate variant Beacons (where i.e. matched variant instances in principle could be connected with the samples they were derived from), “Clinical Beacons” can also be instances of “Evidence” or “Data” Beacons as described in the roadmap - that is, any Beacon providing information about variants or about their instances, useful in a clinical context.
The original Beacon protocol had only limited utility for medical practice or clinical use, mostly in confirming the (non-) existence of a particular variant of interest in connected genome repositories. The protocol itself only permitted the query for single, sequence-specified genome variants and did not allow the addition of any additional information beyond the qualification for the “exists?” query to the Beacon response.
While the Beacon v0.1 => v0.3 only allowed queries for precise (SNP, INDEL) genome variants, v0.4 => 1.n added options for structural variants and range queries. However, no options for biomedical or technical metadata queries had been included.
With version 1.0 of the Beacon API, the addition of the handover response
element now enables the linking of a Beacon query result to any data delivery
method, using labeled URL object(s). The specification itself does not cover
the formats of the handover targets; this is left to the implementer. Right now
(i.e. with v1.n), this strategy allows for the implementation of “data rich”
Beacon responses, where the responsibility for data formats and security stays
with each implementer. Examples for handover implementations using (public)
data are provided in the
Beacon+
implementation, where one e.g. can download the biosample data of the matched
cases, or visualize matched genome variants in the UCSC browser.
While the handover concept is extremely versatile, it does not provide an alignment of response formats across Beacon instances. Therefore, the definition of “clinical response specifications” has become a part of the Beacon v2 roadmap, especially to provide response harmonization for federated queries.
TODO
TODO
