Consider using SchemaBlocks as payload

[mfiume]

For clinical and other kinds of beacons (e.g. an infectious disease beacon we created), it is difficult to return structured data (e.g. patient records) as a flat list of string-only key-value pairs via the info property. Can we consider leveraging SchemaBlocks as a way to return custom or standardized data models in the Beacon payload?

@mbaudis @jfuerth @mcupak

[mbaudis]

@mfiume The currently working way would be to use a handover item (i.e. link object) to point to a data file/stream. You could stick with GA4GH specs by providing then the clinical ... etc. data as phenopackets (or FHIR .... etc.; anything with a GA4GH blessed standard).

IMO the next step for authenticated Beacons v2 is to provide phenopackets directly in a response; I'm not a fan of this (i.e. any direct response which goes beyond variant data), conceptually, but maybe.

Now, if there are other standards blessed by GA4GH, you can push them to an {S}[B] repo; and then they become "reusable", e.g. for Beacon responses (so v2 supports this kind of payload).

[jrambla]

Michael answer is correct. I’ll strongly suggest start looking in the crystalizing Beacon v2 spec. We can help. Best! Jordi From: Michael Baudis [mailto:[email protected]] Sent: Friday, 20 March, 2020 15:52 To: ga4gh-beacon/specification <[email protected]> Cc: Subscribed <[email protected]> Subject: Re: [ga4gh-beacon/specification] Consider using SchemaBlocks as payload (#298) @mfiume<https://github.com/mfiume> The currently working way would be to use a handover item (i.e. link object) to point to a data file/stream. You could stick in the GA4GH specs by providing then the clinical ... etc. data as phenopackets (or FHIR .... etc.; anything with a defined standard). IMO the next step for authenticated Beacons v2 is to provide phenopackets directly in a response; I'm not a fan of this (i.e. any direct response which goes beyond variant data), conceptually, but maybe. Now, if there are other standards blessed by GA4GH, you can push them to an {S}[B] repo; and then they become "reusable", e.g. for Beacon responses (so v2 supports this kind of payload). — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#298 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AB5SEOT2ZKTOWNSZ6BXXHSLRIN7KLANCNFSM4LQNB3AQ>.

[mbaudis]

@mfiume Also with regards to yesterday's call - Some of the issues (e.g. what data v2 is supposed to support in protocol, how you can already use {S}[B] for payload formatting…) are already being addressed; so it is just a question of exploring the documentation & if needed discuss specific needs, improvements, changes:

• Beaconv2 response example for Biosample (draft)
• GeoLocation (e.g. for COVID19 Beacon...)
• Phenopacket's Disease specification

So I think a bit of "proactive alignment" could drive things nicely - challenge & improve what is being developed at the default standard repos!