bbmri-eric / miabis Goto Github PK

@py5gol could you add me with writing rights? Thank you, C

Hosted by Alexander Fürbaß
Cecilia Engels has access

Age unit on the collection level are defined as a "text list", but it should be actually a text value only - if it was a list with more than one element, it would be ambiguous.
https://github.com/BBMRI-ERIC/miabis/blob/master/Data-describing-Sample-Collection.md

• current component on sample, donor & event
• component needs to be updated
• MIABIS mapping to bbmri.de-FHIR: https://samply.github.io/bbmri-fhir-ig/mappings.html
• FHIR Specimen ressource: https://www.hl7.org/fhir/specimen.html
• FHIR ressource specimen committee: http://www.hl7.org/Special/committees/orders/leadership.cfm

Update:

• sample provenance (SPREC, quality)
• additional sample types: organoids, viable PBMC/ cell lines
• data set type & data categories
• sample use requirements (use and access? DUC?)
• donor OR sample OR event-based data model?
• updates from MIABIS 3.0

The status attribute in commection component with description "The state of the Collection functions" and values Active, Ended and Other can be confusing in this context. The current definition leaves room for misinterpretation. Does this mean the collection of new samples and data from donors is active or ended? Collections are usually constantly updated with new data derived from samples, so they can be ‘active’, while no new samples are collected.

• Definition of the scope of the new MIABIS components.
• Identification of a few relevant use-cases for each Dataset Type to base the development work on.
• Approval of the task proposal by BBMRI-ERIC MC -> https://docs.google.com/document/d/1X_oQ9pQhyRFyZUcsAHYXlRQjGy2RtIp5/edit
• Establishment of a working group.
• Alignment with other EU-projects (such as EUCAIM, when possible)
• Development work for new components
• Define use case requirements
• Reach consensus on proposed items for each component based on a series of expert group discussions and formulate proposal for new components
• Expert review and update of proposal
• Final proposal provided to BBMRI-ERIC MC for approval.
• Publication in a peer-reviewed journal and dissemination of results

• Definition of the scope of the new MIABIS components.
• Identification of a few relevant use-cases for each Dataset Type to base the development work on.
• Approval of the task proposal by BBMRI-ERIC MC -> Task initiation document: https://docs.google.com/document/d/1K1GkSLgQDifdfS0PSDg0aIkYrQ12HPXH6eF2enkKVvE/edit
• Establishment of a working group.
• Alignment with other EU-projects (such as canSERV, when possible)
• Development work for new components
• Define use case requirements
• Reach consensus on proposed items for each component based on a series of expert group discussions and formulate proposal for new components
• Expert review and update of proposal
• Final proposal provided to BBMRI-ERIC MC for approval.
• Publication in a peer-reviewed journal and dissemination of results

We need to clarify semantics of collections with respect to persistency and organizationally outlined collections, vs. collections defined around life cycle of samples, SOPs or quality measures implemented, vs. virtual collections created only as workaround for the lack of cubes.

This is a bit of discussion history on the topic:

Petr Holub
Thu 2020-08-13 13:45
Dear both,

there is one more use case I forgot to list - which is currently in place in the Directory
collections used to designate part of the material stored by a biobank that is processed/stored compliant to some standard (this is typically some sub-collection defined for a (subset of) particular material type)
Cheers,
Petr

Assoc. Prof. RNDr. Petr Holub, Ph.D.
Senior IT/Data Protection Manager

BBMRI-ERIC | Neue Stiftingtalstrasse 2/B/6 | 8010 Graz | AUSTRIA
Phone: +43 316 34 99 17-18 | Fax: +43 316 34 99 17-99 | Mobile: +43 664 88 72 18 77
Skype:holubp | [email protected] | www.bbmri-eric.eu
Petr Holub
Wed 2020-08-12 21:45
Dear both,

I think this should be discussed as a part of the MIABIS Core update calls - because that semantics should be defined there. But I suggest that we should have materials prepared for that call where people put together different uses of the collections they have. We have clearly 4 use cases at least:
collections being used just as aggregating statistical descriptors,
collections used to describe certain processes and life cycles of samples in the biobanks (e.g., the long-term vs. short-term collection at MMCI)
collections used to describe purpose for which the material was collected (different studies)
collections used for creating very independent collections (e.g., the NL use case)
If we just start it discussing without having this prepared, the likelihood of productive discussion is rather low. I would appreciate if MIABIS team takes care of facilitating this (Roberto?) - and people fill in their input.

Cheers,
Petr

Assoc. Prof. RNDr. Petr Holub, Ph.D.
Senior IT/Data Protection Manager

BBMRI-ERIC | Neue Stiftingtalstrasse 2/B/6 | 8010 Graz | AUSTRIA
Phone: +43 316 34 99 17-18 | Fax: +43 316 34 99 17-99 | Mobile: +43 664 88 72 18 77
Skype:holubp | [email protected] | www.bbmri-eric.eu
Philip Quinlan
Wed 2020-08-12 14:08
Hi Esther and All,

I think this just emphasises the need to spend some time on this. At the moment we have a one size fits all in relation to Collections, where as we are experiencing that there are several different concepts actually there. That all works OK when we loosely talk about Collections, but once we get into the specifics of collection names, IDs, and levels of persistence the differences emerge.

We should probably arrange a call to try and bring this all together.

All the best,

Phil

Cs-it mailing list
[email protected]
https://lists.bbmri-eric.eu/cgi-bin/mailman/listinfo/cs-it

This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please contact the sender and delete the email and
attachment.

Any views or opinions expressed by the author of this email do not
necessarily reflect the views of the University of Nottingham. Email
communications with the University of Nottingham may be monitored
where permitted by law.
Esther van Enckevort [email protected]
Wed 2020-08-12 11:59
Hi Petr,In the Netherlands the collections are not considered just statistical descriptors, we have several collections, like the Parels from Parelsnoer or the collections under the centralized biobanks in the UMCs that are persistent and are actually considered the biobank in citations, instead of the centralized facility and in most other cases the owners identify much more with the collection than with the biobank entity in the Directory.
Esther van Enckevort
MA, Project Manager

Genomics Coordination Center
UMCG / University of Groningen, Dept. of Genetics
Antonius Deusinglaan 1, 9713 AV Groningen, The Netherlands

Mail: [email protected] | Phone: +31 (0)6 54 33 22 76
Skype: enckevort76 | ORCID: 0000-0002-2440-3993
www.molgenis.org
Petr Holub
Tue 2020-08-11 13:51
Dear Esther,

thanks for the comments.

As for the PID compatibility - we have been through the discussion of PIDs some time ago with Phil and others and the conclusion was that we start with allocating PIDs only to the biobanks and not to the collections. Or if we allocate it to collections too, they should be some kind of "persistent collections" specially marked like that. This is because the collections are primarily aggregators for statistical descriptors as we discussed today during the MIABIS meeting and they can change over the time when the biobank decides that some other structure of those statistical descriptors would characterize its content in a better way. I am about to update the old PID policy - but wanted to do it after we do the practical implementation, because we may run into other problems too and I would like to update it in one go.

As for your second question - I think that we should have at least biobanks citable in the first place. As for the particular collections I think it depends - and the answer might be what I say above (i.e., if you have in NL those collections that need standalone visibility, we would have to mark them as persistent - but their subcollections may not be persistent if they act as statistical aggregators again).

Cheers,
Petr

Assoc. Prof. RNDr. Petr Holub, Ph.D.
Senior IT/Data Protection Manager

BBMRI-ERIC | Neue Stiftingtalstrasse 2/B/6 | 8010 Graz | AUSTRIA
Phone: +43 316 34 99 17-18 | Fax: +43 316 34 99 17-99 | Mobile: +43 664 88 72 18 77
Skype:holubp | [email protected] | www.bbmri-eric.eu
Esther van Enckevort [email protected]
Tue 2020-08-11 11:29
Hi everyone,
The row level security is implemented in the backend, but the frontend for managing is not yet completed. We plan to start testing it with BBMRI-NL soon, and the dev team is looking into the frontend. However, once we implement the persistent identifiers we cannot use simple deletion anyway, because this would break the link with the persistent identifier. At the moment you can delete entities in the staging area, and we actually did build a way to propagate the deletion to the production database, but that hasn't been rolled out yet. As commented above, this would also conflict with requirements for the persistent identifiers.
I did suggest that we circulate this proposal exactly to further define the lifecycle states and the rules regarding state changes. I think it is not a trivial thing to properly identify the valid states so it is important that we take the time to discuss them. From BBMRI-NL I also got some input that for the requestor the main interest is whether the collection is still including more subjects and whether there is still more data/samples collected for the subject and according to them collections that don't have anything available to be requested should not be part of the Directory. This touches the fundamental question that Phil also raised about what we want the Directory to represent. Is it a tool to find collections from which you can request samples/data or do we have a broader goal to also make collections citable.
I'm happy that we started this discussion and i hope others will also give their input.

With kind regards,

Esther
Cs-it mailing list
[email protected]
https://lists.bbmri-eric.eu/cgi-bin/mailman/listinfo/cs-it

--
Esther van Enckevort
MA, Project Manager

Genomics Coordination Center
UMCG / University of Groningen, Dept. of Genetics
Antonius Deusinglaan 1, 9713 AV Groningen, The Netherlands

Mail: [email protected] | Phone: +31 (0)6 54 33 22 76
Skype: enckevort76 | ORCID: 0000-0002-2440-3993
www.molgenis.org
A.S. [email protected]
Mon 2020-08-10 15:29
Hi,
You are really watchful Petr.

To tell you the truth, I was thinking about only one flag - used for deletion. The Depleted state came to my mind at once as a possible usage extension. But then we started exchange of thoughts and emails, some new states appeared in them, and I devoted them not enough reasoning.

Obviously, we can use this one flag only for the likely states of the collection life cycle that are excluding themselves. But before we come up to an agreement, it could be nice to decide at least on deletion. It would give us solution for automatic (API) management of collections (and biobanks, contacts and networks).

Andrzej

Pobierz aplikację BlueMail dla systemu Android
W dniu 10 sie 2020, o 13:55, użytkownik Petr Holub [email protected] napisał:
Dear all,

I think we are facing here 2 issues:

1. Marking the status of the collection - and I like the generalizing approach. A couple of comments from my side:

As for those flags om general, I guess it's meant to set those flags independently - so that it's not meant as a state of the collection, rather just flags describing its properties in the given moment in time. The reason for commenting: if it was meant as a state, we would perhaps need to have states described in a such a way that a collection can be in exactly one of the states. While as it looks now, at least some of the flags may be combined (e.g., recruiting + on site use only).
If the above assumption is correct, you should also define rules for forbidden combinations (e.g., deleted + recruiting does not make sense)
Depleted has at least 2 sub-states: "operationally depleted", when samples can no longer be handed out and only reference samples are kept for reproducibility verification, and "completely depleted" when all samples including references ones are gone.
Archived flag is a bit complicated for me - what is its relation to (or difference to) Deleted and Depleted?

2. What I don't like is that the problem is indirectly induced by the use of staging area. We have discussed since 2-3 years at least that we should be able to avoid the staging area completely once we have column/row level security. I believe this has already been delivered - so I don't understand why we are still using the staging area when it's causing troubles... Morris, Esther?

Thanks,
Petr

Assoc. Prof. RNDr. Petr Holub, Ph.D.
Senior IT/Data Protection Manager

BBMRI-ERIC | Neue Stiftingtalstrasse 2/B/6 | 8010 Graz | AUSTRIA
Phone: +43 316 34 99 17-18 | Fax: +43 316 34 99 17-99 | Mobile: +43 664 88 72 18 77
Skype:holubp | [email protected] | www.bbmri-eric.eu

• RD-Connect
• BBMRI-ERIC Directory
• Biobank Graz?
• BBMRI-ERIC Cohort?

https://drive.google.com/drive/folders/1etEfNqx0QDnTqJHoJ3j_gJACd7WAPacG

• Review and finalise

• Publish short general description of MIABIS on BBMRI-ERIC webpage
• Description of MIABIS aim, community, work process and current status
• https://www.bbmri-eric.eu/

Matthias Brockhausen is no longer available for MIABIS

It is important to finish the ongoing discussion on how to express combinations of various categories - the proposals we have for data cubes implemented via star model.

MIABIS Glossary for wiki pages to help clarifying internal terminology on components, entities, attributes etc.

From this one:
https://github.com/MIABIS/miabis/blob/master/Data-describing-Sample-Collection.md

Link to:
MIABIS-2.0-16
leads to
https://github.com/MIABIS/miabis/wiki#collection-type
which is, however, empty.

There is a question coming from the BBMRI.nl:

I have a question we got from a large Dutch project: they would like to add quite a lot of collections to the BBMRI-NL catalogue, but most studies have RCT for collection type and they asked if we could add that one as an option. We heard this request before and could do that, but than we have the issues of mapping to the Directory. Thinking about it I was actually surprised RCT is not an option yet since it is very common, so I thought there must be a good reason why this one is not there (yet). Do you have an idea why?
Otherwise, is it an idea to add RCT as an collection type? And if not, do you know what would be a substitute that already exists in the Directory?

Can MIABIS group consider to add this collection type to the MIABIS Core?

• Medical/clinical data models analysis - OMOP, IPS, HL7 (?)
• Monitoring the EHDS1 EHDS2 projects of DG Sante [GUMed]
• Monitoring the EHDEN project (European OHDSI)
• Monitoring HL7 and German Medical Informatics Initiative

• Samples for which all parameters are identical are considered to be a single sample and will be counted only once
• Aliquots for which all parameters from the profile are identical are considered to be a single sample
• Tissue slides are to be counted as different samples, not aliquots, because they are not similar

• Biobank, Collection & Network attributes updated
• Proposal for MC written and submitted
• Publish Update of MIABIS V3.0

BBMRI-CS-IT

WP4 Meeting Notes (08-09-2020):
• To define what ‘collection’ is, the semantics thereof.
• Transfer the email discussion (about ‘collection’) to the MIABIS GitHub webpage.
• MIABIS GitHub webpage will henceforth ‘record all issues’.

“cohort” refers to donors, not to samples

• but only applicable research biobanks
• but not really applicable for “residual material” collections

Please consider if MIABIS should come also with documentation of constraints on the data models and how data quality checks shall be implemented. As BBMRI.pl (Andrzej) pointed out, we are lacking systematic documentation of these - and what does not fit into MIABIS will need to go into the Directory data model documentation.

Current data quality checks are documented via its implementation ;) at
https://github.com/esthervanenckevort/molgenis-app-bbmri-eric-scripts