search

clingen-data-model / allele

Documentation for data model of ClinGen
10 stars 2 forks source link

Use cases for interpretation editing/approval #174

Closed cbizon closed 3 years ago

cbizon commented 8 years ago

I'm not clear on the way that edits are going to be handled in the model. So person A makes an interpretation, and then person B goes to look at it, and wants to change something. Maybe they add or remove evidence, or change a rule from strong to supporting. So we're saying that this will be a new interpretation, right?

That interpretation will have wasGeneratedBy pointing to the old interpretation, and it will have its own GenerateInterpretation activity (or whatever that 3rd activity is called). The entities that feed into that are actually mostly the same entities as in the first interpretation (same id and prov etc), except for whatever changes were made, right?

bpow commented 8 years ago

I agree with the overall idea, but I'm not sure that wasGeneratedBy is the right relationship to use here. I think it makes more sense to say that the new interpretation wasDerivedFrom the old one.

I don't know if it is worth modelling a 'ReviseInterpretation' separate from a 'GenerateInterpretation' (so it could, for instance, only include the "delta" between the evidence used and the interpretation), or maybe allow any 'GenerateInterpretation' to refer to a prior revision, in which case it would represent a 'ReviseInterpretation' activity.

cbizon commented 8 years ago

Thanks for pointing that out. Indeed, wasDerivedFrom is the one I meant to say.

cbizon commented 8 years ago

Outcome of discussion on the DMWG:

There are several use cases in play:

  1. Internally to Variant Curation App, multiple versions of an interpretation are created based on old versions, either due to continued work or because an approver or somebody else modified it. We decided that while this use case might be important to the app working group, neither producers nor consumers of interpretations really wanted this level of process exposed.
  2. Approval creates a new interpretation (an approved interpretation) based on an old interpretation. This might require a wasDerivedFrom attribute. However, the group decided that a change in state of the interpretation probably should not be modeled by creating a new interpretation class or entity. Rather we model the state separately and provide provenance for that state (the publish/approve activity).
  3. A new interpretation might be derived from a previous version of a published interpretation. Reinterpretation is common, and we still need to plumb this workflow and decide to what level do we want to get to. For instance, as @bpow was pointing out, maybe we actually have individual CriterionAssessments in the new model derived from assessments in the old model.

Because this third use case is valid, I'm going to leave this open, assigned to @larrybabb since I think he is working on the high level use-cases/examples.