@ramonski forced me to start a topic about the need of secondary sample functionality, that has (temporarily?) disappeared in the current development after the great concept change from ARs to samples as the main entity.
At the moment secondary samples are created only after invalidation with a new sample id ruled by the id-server. Additionally you can copy an existing sample into a new one.
I still see several use-cases, where those ways are not sufficient, e.g. because invalidation isn’t wanted or copying sample will not keep the original sample id or received date.
- client requests supplementary analyses after publication
- wrong analysis profile
- client requests a full retest for whatever reason
- report should contain primary and secondary AS of a sample bound together
- simply change sample metadata after publication (client feedback)
- client or other client (edge case) requests independent additional analyses
- no one wants to change/add labels and stickers of samples and partitions out of the storage
Surely some of you will see more…
In senaite up to 1.2 I liked the possibility in AR registration to choose an existing sample to create a secondary request on that.
This might be a useful way for this task.
Creating new sample ids can be OK, if senaite links primary and secondary samples similar to invalidations.
At least the old concept of analysis requests using a suffix to the sample id was a smart idea for this case.
Maybe the partition functionality can be adapted for this purpose?
What are you thinking?
Thanks @grulisco for sharing your thoughts and use-cases.
@xispa and me discussed already some possible ways how to implement this in the system and thought about “proxying” (passthrough) of the initial Sample fields to the secondary Sample (aka AR in Senaite up to 1.2.9).
However, I think it might be all done in the Add Form by a simple checkbox “Secondary”, stating that this is a secondary Sample. Then the Core machinery would do the linkage and mark the Sample with an interface like in https://github.com/senaite/senaite.core/pull/1228 (well done @xispa!).
The ID could then be correctly generated and the received date could be set according to the original Sample when receiving the secondary.
The only disadvantage (advantage?) is that changes in the original Sample are not visible in the secondary Samples, because the values are copied and not passed by reference. This was especially the case in Senaite up to 1.2.9, which I think was confusing to the user because of this implicit side-effect.
I’d like the resemble secondary sample ids with a suffix like the partitions. (as in #1228).
But we have think about cases when secondary samples get partioned too…
there’s lots of mention of senaite 1.3. is that senaite core 1.3 or senaite lims 1.3?
in either case are they released yet
@mgarner19801 , we are referring to
senaite.core 1.3 (current
master branch from senaite.core repository). This new version will be released within the following days.
Thanks a lot!
Keep up the good work.
Do secondary samples will be incorporated into Senaite 1.3? Which approach was used?
Yes @leo, secondary samples functionality has been incorporated into Senaite 1.3. It follows the same approach as before, except that the suffix that comes by default with secondaries is now
S-02, etc. Check the Pull Request for further info: https://github.com/senaite/senaite.core/pull/1284