Διαχείριση εκπρόθεσμης διακρίβωσης

Στόχος

Όταν προσπαθείτε να εγκρίνετε ένα Αρχείο Ανάλυσης (Analysis Record — AR) και η έγκριση μπλοκάρεται επειδή η διακρίβωση κάποιου εκ των οργάνων μέτρησης είναι εκπρόθεσμη, ο οδηγός αυτός περιγράφει τις δύο επιτρεπτές οδούς επίλυσης σύμφωνα με το ΕΛΟΤ ΕΝ ISO/IEC 17025:2017:

• Επιλογή Α — Διακρίβωση τώρα: η συνιστώμενη οδός. Διακριβώνετε το όργανο, καταχωρείτε νέο CalibrationRecord με ενημερωμένη ημερομηνία επόμενης διακρίβωσης και επανεκκινείτε την έγκριση.
• Επιλογή Β — Τεκμηριωμένη παράκαμψη: η οδός εξαίρεσης. Ο Διευθυντής Εργαστηρίου (LAB_DIRECTOR), ο Διαχειριστής Ποιότητας (QUALITY_MANAGER) ή ο Αξιολογητής (REVIEWER) εγκρίνει χωρίς διακρίβωση, καταγράφοντας αιτιολογία ≥20 χαρακτήρων. Η παράκαμψη ελέγχεται μέσω καταχώρησης σε audit log.

Καμία από τις δύο οδούς δεν παρακάμπτεται σιωπηλά — κάθε έγκριση επί εκπρόθεσμου οργάνου αφήνει ίχνος στο σύστημα.

---

Προϋποθέσεις

Όργανα με requiresCalibration = false (π.χ. ογκομετρικά γυάλινα σκεύη, χειρωνακτικά εργαλεία) ή χωρίς συμπληρωμένη nextCalibrationDate εξαιρούνται αυτόματα και δεν προκαλούν αποκλεισμό.

Έλεγχος πριν αποφασίσετε οδό

Πριν επιλέξετε ανάμεσα σε Α και Β, ανοίξτε την καρτέλα Μετρήσεις του AR και σημειώστε:

• Ποια όργανα είναι εκπρόθεσμα — συνήθως ένα ή δύο, σπάνια όλα. Αν μόνο ένα όργανο μπλοκάρει, η οδός Α είναι σχεδόν πάντα η σωστή.
• Πόσο εκπρόθεσμη είναι η διακρίβωση — μία μέρα μετά τη λήξη απαιτεί διαφορετική αιτιολόγηση από έναν μήνα.
• Αν υπάρχει εν εξελίξει CAPA για το όργανο — η οδός Β πρέπει να συνδεθεί με υπάρχουσα ή νέα διορθωτική ενέργεια.

---

Βήματα

1. Δοκιμάστε την έγκριση. Στη σελίδα Λεπτομερειών του AR, πατήστε το κουμπί «Έγκριση» στη σειρά ενεργειών — δεν βρίσκεται σε μενού kebab, εμφανίζεται απευθείας. Εφόσον υπάρχει εκπρόθεσμο όργανο, το backend επιστρέφει σφάλμα με κωδικό APPROVAL_BLOCKED_CALIBRATION_OVERDUE. Το frontend αναγνωρίζει τον κωδικό και ανοίγει το παράθυρο παράκαμψης αντί για snackbar σφάλματος, παρουσιάζοντας τη λίστα των εκπρόθεσμων οργάνων (όνομα, αριθμός σειράς, ημερομηνία λήξης διακρίβωσης).
2. Επιλογή Α — Διακρίβωση τώρα (συνιστώμενη).

• Κλείστε το παράθυρο παράκαμψης με Ακύρωση.
• Πλοηγηθείτε στη σελίδα Όργανα → επιλέξτε το όργανο.
• Στην καρτέλα Διακριβώσεις καταχωρήστε νέο CalibrationRecord. Συμπληρώστε:
• calibrationDate — η σημερινή ημερομηνία διακρίβωσης.
• withinTolerance: true — το όργανο πέρασε τον έλεγχο.
• nextDueDate — η προτεινόμενη επόμενη ημερομηνία διακρίβωσης βάσει της συχνότητας του SOP (π.χ. + 12 μήνες). Προσοχή: αυτό είναι ιστορικό πεδίο πάνω στην ίδια την εγγραφή διακρίβωσης — δεν ενημερώνει αυτόματα το όργανο.
• Αρχείο τεκμηρίωσης (αριθμός πιστοποιητικού διακρίβωσης διαπιστευμένου φορέα ή ενδοεργαστηριακό πρωτόκολλο, στο πεδίο σημειώσεων).
• Κρίσιμο βήμα που παραλείπεται εύκολα: η αποθήκευση του CalibrationRecord ΔΕΝ ενημερώνει από μόνη της το πεδίο nextCalibrationDate του Οργάνου — αυτό είναι το πεδίο που πραγματικά ελέγχει ο guard έγκρισης. Ανοίξτε ξεχωριστά τη φόρμα επεξεργασίας του ίδιου του Οργάνου (όχι την καρτέλα Διακριβώσεις) και ενημερώστε το πεδίο «Επόμενη Διακρίβωση» σε μελλοντική ημερομηνία, μετά αποθηκεύστε.
• Επιστρέψτε στο AR και ξανατρέξτε την Έγκριση. Πλέον ο έλεγχος περνά καθαρά και το AR μεταβαίνει σε Εγκεκριμένη χωρίς καταγραφή παράκαμψης.

1. Επιλογή Β — Τεκμηριωμένη παράκαμψη (οδός εξαίρεσης).

• Στο παράθυρο παράκαμψης που έχει ήδη ανοίξει, συμπληρώστε την αιτιολογία παράκαμψης στο πεδίο κειμένου. Πρέπει να αναφέρετε:
• γιατί η διακρίβωση δεν μπορεί να γίνει άμεσα,
• γιατί η αποδέσμευση των αποτελεσμάτων είναι μετρολογικά αποδεκτή παρόλα αυτά (π.χ. ισχύς εσωτερικού QC με γνωστό υλικό αναφοράς, εύρος ικανότητας ελεγχόμενο),
• ποια ενέργεια διόρθωσης έχει προγραμματιστεί (CAPA, διακρίβωση εντός Χ ημερών).
• Το πεδίο απαιτεί τουλάχιστον 20 χαρακτήρες· διαφορετικά η υποβολή απορρίπτεται.
• Πατήστε Υποβολή. Το AR μεταβαίνει σε Εγκεκριμένη και καταγράφεται στο μητρώο ελέγχου (audit trail) ένα event OVERRIDE_CALIBRATION_APPROVE με τα πεδία userId, entityType = 'AnalysisRecord', entityId, reason, χρονοσφραγίδα και τη λίστα των εκπρόθεσμων οργάνων ως changes.

1. Επιβεβαίωση καταχώρησης. Στο AR, η καρτέλα «Ιστορικό Εγγραφής» (Record History) εμφανίζει την εγγραφή με την πλήρη αιτιολογία και τον υπεύθυνο. Δεν διαγράφεται ποτέ — αποτελεί μέρος του αρχείου αξιολόγησης για τον επιθεωρητή ΕΣΥΔ.

Αυτή η καρτέλα δείχνει απλή λίστα, χωρίς φίλτρο ή εξαγωγή CSV. Για να φιλτράρετε ανά ενέργεια (OVERRIDE_CALIBRATION_APPROVE) και να εξάγετε CSV για το φάκελο εσωτερικής επιθεώρησης, χρησιμοποιήστε τη σελίδα Ιστορικό Ελέγχου (/audit-trail — απαιτεί το δικαίωμα «Ιστορικό Ελέγχου»). Η εξαγωγή περιλαμβάνει χρήστη, χρονοσφραγίδα, αιτιολογία και τα σχετικά δεδομένα, που είναι ακριβώς το είδος τεκμηρίωσης που ζητάει η §6.4.7.

1. Παρακολούθηση εκκρεμοτήτων. Από τον Επιχειρηματικό Πίνακα (Business Dashboard), η κάρτα «Έσοδα σε Κίνδυνο (Διακρίβωση)» δείχνει το τιμολογηθέν έσοδο των παραγγελιών δειγμάτων που αγγίζουν εκπρόθεσμα όργανα (όχι μια ουρά εκκρεμών εγκρίσεων) — αν έστω ένα δείγμα μιας παραγγελίας αναλύθηκε σε εκπρόθεσμο όργανο, όλη η παραγγελία μετράει ως εκτεθειμένη. Χρησιμοποιήστε την για να ιεραρχήσετε ποια όργανα χρειάζονται διακρίβωση πρώτα.

Πρότυπο αιτιολογίας παράκαμψης

Για να αποφύγετε επανειλημμένες απορρίψεις λόγω ανεπαρκούς τεκμηρίωσης, ακολουθήστε τη δομή:

«Η διακρίβωση του οργάνου <όνομα> (S/N <serial>) έληξε στις <ημερομηνία>. Δεν μπορεί να γίνει άμεσα διότι <λόγος — π.χ. αναμένεται επίσκεψη παρόχου, αναπληρωματικό όργανο σε χρήση>. Η μετρολογική εμπιστοσύνη διατηρείται μέσω <εσωτερικό QC με υλικό αναφοράς LotXXX εντός ορίων / διπλή ανάλυση με αναπληρωματικό όργανο>. Έχει ανοιχθεί CAPA-<αριθμός> και η διακρίβωση έχει προγραμματιστεί για <ημερομηνία>.»

---

Τι συμβαίνει στο παρασκήνιο

Η λογική αποκλεισμού υλοποιείται στη μέθοδο _enforceCalibrationGuard του analysis-record.resolver.ts (γύρω στη γραμμή 967). Για κάθε Measurement του AR συλλέγονται τα μοναδικά instrumentId και ζητείται ο πίνακας Instrument όπου requiresCalibration = 1, nextCalibrationDate IS NOT NULL και nextCalibrationDate < CURDATE(). Αν δεν προκύψουν εγγραφές, ο guard περνά αμέσως· διαφορετικά, χωρίς overrideReason, ρίχνεται GraphQLError με κωδικό extension APPROVAL_BLOCKED_CALIBRATION_OVERDUE και payload instruments[] που περιλαμβάνει id, name, serialNumber, nextCalibrationDate.

Το πεδίο nextCalibrationDate στο Instrument (instrument.entity.ts, γύρω στη γραμμή 67) είναι nullable string τύπου date — η πολιτική σύγκρισης χρησιμοποιεί τη συνάρτηση CURDATE() του MariaDB, οπότε όλα τα όργανα του ίδιου tenant ελέγχονται με ενιαία ζώνη ώρας server. Όργανα με nextCalibrationDate IS NULL δεν προκαλούν μπλόκο.

Στην οδό παράκαμψης, ο κοινός βοηθός OverrideHelper.assertAndRecord() (common/override.helper.ts) ελέγχει διαδοχικά:

1. Ότι ο ρόλος ικανοποιεί isOverrideRole(role) — διαφορετικά απορρίπτεται με το μήνυμα errors.overrideCalibrationDenied. Ο έλεγχος δεν είναι hard-coded στους τρεις ρόλους — διαβάζει την καταχώρηση QUALITY_SYSTEM_OVERRIDE του πίνακα δικαιωμάτων του tenant (Ρυθμίσεις → Δικαιώματα Ρόλων), της οποίας η προεπιλογή είναι ακριβώς LAB_DIRECTOR + QUALITY_MANAGER + REVIEWER, αλλά μπορεί να αλλάξει.
2. Ότι το reason.trim().length >= 20 (η σταθερά MIN_OVERRIDE_REASON_LENGTH) — διαφορετικά απορρίπτεται με το μήνυμα errors.overrideReasonTooShort.
3. Καλεί recordEvent({ action: 'OVERRIDE_CALIBRATION_APPROVE', ... }), που γράφει την εγγραφή στον κοινό πίνακα AuditTrail (όχι σε ξεχωριστό «OverrideLog» — είναι ο ίδιος πίνακας όπου καταγράφονται όλα τα γεγονότα ελέγχου του tenant).

Η ακολουθία ελέγχων είναι σκόπιμα fail-fast: ένας χρήστης χωρίς ρόλο δεν θα δει ποτέ μήνυμα τύπου «η αιτιολογία είναι πολύ σύντομη», ώστε να μην εξάγει πληροφορίες για το πώς να παρακάμψει.

Σύντομη δίγλωσση περιγραφή είναι ενσωματωμένη στο ίδιο το μήνυμα σφάλματος του guard, οπότε ακόμη και εργαλεία που δεν προβάλλουν το extensions.instruments (π.χ. απευθείας curl) εμφανίζουν ποιο όργανο είναι εκπρόθεσμο.

Στο frontend, ο component AnalysisDetail (analysis-detail.ts, γύρω στις γραμμές 840-862) εντοπίζει τον κωδικό σφάλματος μέσα στο err.errors[0].extensions.code (Apollo v4 shape) και ενεργοποιεί το παράθυρο παράκαμψης μέσω showOverrideDialog.set(true), αποθηκεύοντας το recordId σε pendingApprovalRecordId. Η υποβολή της αιτιολογίας καλεί ξανά τη mutation, αυτή τη φορά με το overrideReason σαν παράμετρο — η ίδια ροή guard τρέχει εκ νέου, βλέπει το reason, και προχωρά στην καταγραφή.

Ακραίες περιπτώσεις

• Όργανο που έχει χρησιμοποιηθεί σε μέτρηση δεν μπορεί να διαγραφεί. Η στήλη instrumentId στο Measurement έχει ξένο κλειδί χωρίς CASCADE προς το Instrument — η διαγραφή του οργάνου θα αποτύχει με σφάλμα ξένου κλειδιού όσο υπάρχει έστω μία μέτρηση που το αναφέρει. Το σενάριο «διαγραμμένο όργανο με ορφανή μέτρηση» δεν μπορεί επομένως να συμβεί μέσω της κανονικής εφαρμογής.
• Πολλαπλά εκπρόθεσμα όργανα στο ίδιο AR: το παράθυρο παράκαμψης εμφανίζει όλα. Η ίδια αιτιολογία καλύπτει το σύνολο — δεν χρειάζεται ξεχωριστή υποβολή ανά όργανο.
• Διακρίβωση εκτός tolerance (withinTolerance: false): ανεξάρτητα από την τιμή του withinTolerance, η αποθήκευση του CalibrationRecord ΔΕΝ ενημερώνει ποτέ αυτόματα το Instrument.nextCalibrationDate — αυτό γίνεται πάντα χειροκίνητα στη φόρμα του Οργάνου (βλ. Επιλογή Α παραπάνω). Μια διακρίβωση εκτός ορίων είναι απλώς ένας επιπλέον λόγος να ΜΗΝ προχωρήσετε σε αυτή τη χειροκίνητη ενημέρωση.

Σημαντική διαφορά για bulk approve. Η μέθοδος μαζικής έγκρισης (analysis-record.resolver.ts, γύρω στη γραμμή 1787) καλεί _enforceCalibrationGuard(r, undefined, userRole, userId) με overrideReason = undefined, οπότε δεν επιτρέπεται καμία παράκαμψη: όλα τα AR με εκπρόθεσμο όργανο αποτυγχάνουν και πρέπει να διορθωθούν είτε μεμονωμένα με reason είτε με πραγματική διακρίβωση. Αυτό είναι σκόπιμο — η μαζική έγκριση δεν πρέπει να καλύπτει εξαιρέσεις.

Αν χρειάζεται να αδειάσετε μια μεγάλη ουρά, η ροή εργασίας είναι:

1. Τρέξτε τη μαζική έγκριση για να εντοπίσετε ποια AR αποτυγχάνουν.
2. Ομαδοποιήστε τις αποτυχίες ανά όργανο.
3. Διακριβώστε πρώτα τα όργανα που ευθύνονται για τις περισσότερες αποτυχίες.
4. Ξανατρέξτε τη μαζική έγκριση· τυχόν υπόλοιπες αποτυχίες τις χειρίζεστε μία-μία μέσω του παραθύρου παράκαμψης με πλήρη αιτιολογία.

---

Σχετικά εδάφια

• §6.4.6 — Διακρίβωση οργάνων μέτρησης για ιχνηλασιμότητα. Όλα τα όργανα που επηρεάζουν την αβεβαιότητα μέτρησης πρέπει να διακριβώνονται σύμφωνα με τεκμηριωμένο πρόγραμμα. Η εκπρόθεσμη διακρίβωση συνεπάγεται αμφισβητούμενη ιχνηλασιμότητα.
• §6.4.7 — Πρόγραμμα διακρίβωσης και επανεξέταση. Το εργαστήριο τεκμηριώνει συχνότητες διακρίβωσης, ενδιάμεσους ελέγχους, και εξετάζει το πρόγραμμα όταν εντοπίζονται αποκλίσεις. Η οδός παράκαμψης πρέπει να συνοδεύεται από CAPA που τροφοδοτεί την επανεξέταση.

Για το πλήρες κείμενο των εδαφίων δείτε τη σελίδα Αναφορά → ISO/IEC 17025:2017.

---

Συμβουλή για επιθεωρήσεις ΕΣΥΔ

Οι επιθεωρητές ΕΣΥΔ συχνά ζητούν δειγματοληπτικά να δουν παραδείγματα παρακάμψεων. Μια καλά δομημένη εγγραφή στο μητρώο ελέγχου (AuditTrail) με σαφή αιτιολογία, παραπομπή σε CAPA και αποδείξεις μετρολογικής εμπιστοσύνης (QC charts, αναπληρωματικές μετρήσεις) αποτελεί ισχυρή απόδειξη ότι το εργαστήριο δεν παρακάμπτει σιωπηλά τους ελέγχους, αλλά διαχειρίζεται την εξαίρεση με ώριμο τρόπο. Αντίθετα, λακωνικές αιτιολογίες του τύπου «έκτακτη ανάγκη» είναι κόκκινη σημαία.

Συστηματική χρήση της οδού Β (π.χ. πάνω από 5 παρακάμψεις/μήνα για το ίδιο όργανο) πρέπει να ενεργοποιεί ανασκόπηση του προγράμματος διακρίβωσης σύμφωνα με τη §6.4.7 και ενδεχομένως αύξηση της συχνότητας ή αλλαγή παρόχου.