Γιατί η §7.4.3 ζει στην παραλαβή

Η §7.4.3 του ISO/IEC 17025:2017 απαιτεί καταγεγραμμένη διαβούλευση με τον

πελάτη όταν ένα δείγμα φτάνει στο εργαστήριο σε κατάσταση που αποκλίνει από

την προβλεπόμενη — σπασμένο, ακατάλληλα συντηρημένο, με ελλιπή ταυτοποίηση,

εκτός θερμοκρασίας μεταφοράς. Ο τρόπος με τον οποίο ένα LIMS υλοποιεί αυτή

τη ροή είναι αποκαλυπτικός για το πώς αντιμετωπίζει το συνολικό audit trail.

Το πρόβλημα της ξεχωριστής ροής

Τα περισσότερα LIMS (LabWare, STARLIMS, Labvantage σε προεπιλεγμένες παραμετροποιήσεις) υλοποιούν την §7.4.3 ως ξεχωριστή οντότητα — «Customer Consultation» με δική της σελίδα, δικό της κλειδί, δικό της λίστα και δικό της κουμπί «Νέα διαβούλευση». Όταν ο αναλυτής σημειώσει conditionOnArrival ≠ OK, ένα banner τον στέλνει σε άλλη φόρμα.

Αυτή η αρχιτεκτονική δημιουργεί τρία προβλήματα:

1. Διαχωρισμός των αποδεικτικών στοιχείων. Η κατάσταση του δείγματος ζει στον πίνακα samples, η διαβούλευση σε customer_consultations. Ο επιθεωρητής πρέπει να ακολουθήσει FK lookup για να επιβεβαιώσει ότι κάθε «μη-OK» δείγμα έχει αντίστοιχη εγγραφή — και να ζητήσει εξήγηση για κάθε ορφανή περίπτωση.
2. Δυνατότητα απόκλισης (drift). Ένας χρήστης μπορεί να αλλάξει το conditionOnArrival αργότερα χωρίς να ενημερώσει τη συνδεδεμένη διαβούλευση — δύο εγγραφές, δύο πηγές αλήθειας, καμία βάση δεδομένων δεν μπορεί να επιβάλλει συνέπεια μέσω constraint.
3. Κόστος UX. Ο αναλυτής βλέπει το δείγμα μπροστά του, αλλά πρέπει να μεταβεί αλλού για να καταγράψει τη συζήτηση που μόλις ολοκλήρωσε στο τηλέφωνο. Η τριβή αυτή ευνοεί την παράλειψη.

Η απόφαση: inline στη φόρμα παραλαβής

Στο Agrometrisis η διαβούλευση ζει ως στήλες πάνω στην ίδια οντότητα

Sample: customerConsultedAt, customerConsultedById, consultationOutcome,

customerAuthorisedProceed, consultationNotes.

Η φόρμα παραλαβής ανοίγει το υπο-μπλοκ §7.4.3 αυτόματα μέσω applyWhen() πάνω

στο conditionOnArrival ≠ OK — με κόκκινο αριστερό περίγραμμα, υποχρεωτικά

πεδία και απευθείας σύνδεση με την §-clause. Τα πεδία αποθηκεύονται με το ίδιο

save· δεν υπάρχει «μην ξεχάσετε να συμπληρώσετε και...» υπενθύμιση.

Γιατί ικανοποιεί καλύτερα τον έλεγχο

Ο επιθεωρητής ΕΣΥΔ που περπατάει το audit trail βλέπει την κατάσταση του δείγματος και τη διαβούλευση στην ίδια γραμμή. Δεν υπάρχει FK lookup, δεν υπάρχει «η σχετική εγγραφή είναι σε άλλη οθόνη». Η §7.4.3 ζητάει αποδεικτικά στοιχεία για το συγκεκριμένο δείγμα — άρα τα αποδεικτικά στοιχεία ζουν στο δείγμα.

Κλείσιμο βρόχου με μεταβάσεις κατάστασης

Το consultationOutcome έχει τρεις τιμές: Προχώρα ώς έχει (με αποποίηση), Απόρριψη δείγματος, Αίτημα επανάληψης δειγματοληψίας. Όταν αποθηκευτεί:

• Απόρριψη δείγματος → το δείγμα μεταβαίνει αυτόματα σε Απορρίφθηκε με noteCode: SAMPLE_REJECTED_BY_CUSTOMER στο status log.
• Αίτημα επανάληψης δειγματοληψίας → μεταβαίνει σε Ακυρώθηκε με SAMPLE_CANCELLED_FOR_RESAMPLING.
• Προχώρα ώς έχει (με αποποίηση) → απαιτεί επιπλέον customerAuthorisedProceed=true, χωρίς αλλαγή κατάστασης.

Έτσι, η απόφαση του πελάτη γίνεται πράξη στο σύστημα — όχι σημείωση που μπορεί να ξεχαστεί.

Το trade-off

Η ξεχωριστή ροή δίνει «δωρεάν» μια λίστα διαβουλεύσεων ως ξεχωριστή οντότητα. Στο Agrometrisis η ίδια λίστα προκύπτει με ένα φίλτρο στη σελίδα δειγμάτων: consultationOutcome IS NOT NULL. Ένα query, μηδέν πρόσθετη οντότητα, μία πηγή αλήθειας — και ως bonus, η λίστα κουβαλάει αυτόματα όλο το context του δείγματος (πελάτης, μέθοδος, αναλυτής) χωρίς πρόσθετα joins.

Όταν επιλέγετε LIMS, αξίζει να ρωτήσετε τον προμηθευτή: «δείξτε μου πώς ένας επιθεωρητής επαληθεύει σε δέκα δευτερόλεπτα ότι ένα συγκεκριμένο "μη-OK" δείγμα έχει καταγεγραμμένη διαβούλευση». Αν η απάντηση περιλαμβάνει την πλοήγηση σε άλλη οθόνη, η §7.4.3 αντιμετωπίζεται ως δευτερεύουσα ροή — όχι ως αναπόσπαστο μέρος της παραλαβής.