Περί "TaxisNet για την Υγεία"

Διάβασα στο ΒΗΜΑ της 3/4/2010 ένα άρθρο σχετικά με την υλοποίηση ενός συστήματος ηλεκτρονικής συνταγογράφησης.

Το σύστημα, όπως περιγράφεται, θα παρέχει από ακρου-σε-άκρο λειτουργίες για την κάλυψη των αναγκών συνταγογράφησης από γιατρούς και εκτέλεσης συνταγών από φαρμακεία.

Εάν το σύστημα αυτό έχει ήδη προδιαγραφεί και η Πολιτεία σκοπεύει να το υλοποιήσει με τον τρόπο που περιγράφεται στο άρθρο, τότε πρόκειται για άλλη μιά περίπτωση όπου μιά υπαρκτή ανάγκη (ο έλεγχος των δαπανών υγείας των ασφαλιστικών ταμείων) θα πέσει θύμα της αδυναμίας λήψης πραγματικά πολιτικών αποφάσεων και εκχώρησης τους σε «ειδικούς» που δεν έχουν όμως πραγματική αντίληψη του τρόπου λειτουργίας των εμπλεκομένων στη λειτουργία του συστήματος.

Τo σύστημα αυτό, όπως περιγράφεται στο άρθρο, δεν μπορεί να είναι πραγματικά λειτουργικό για μιά σειρά από λόγους, καθώς:

1. Δεν λαμβάνει υπόψη του τις πραγματικές ανάγκες των επαγελματιών που θα το χρησιμοποιούν (γιατροί, φαρμακοποιοί). Π.χ. έχει ληφθεί υπόψη του ο χρόνος που θα χρειάζεται ένας γιατρός για να συμπληρώνει μιά συνταγή; Τι λειτουργίες θα του παρέχει το σύστημα ώστε να είναι εύχρηστο;
2. Δε φαίνεται να έχουν ληφθεί υπόψη οι ανάγκες των τελικών χρηστών για υποστήριξη. Για να λειτουργήσει ένα τέτοιο σύστημα θα πρέπει να συνοδεύεται και από ένα μηχανισμό υποστήριξης ικανό να απαντά σε εξειδικευμένα ερωτήματα. Από τον ενδεικτικό (εξαιρετικά χαμηλό κατά τη γνώμη μου) προϋπολογισμό που παρατίθεται στο άρθρο δεν προκύπτει ότι κάτι τέτοιο έχει προβλεφθεί.
3. Για να λειτουργήσει το σύστημα θα πρέπει οι τελικοί του χρήστες να εξοικειωθούν με τη χρήση τόσο της βασικής λειτουργικότητας όσο και με τη χρήση συσκευών (π.χ. bar-code readers) και (κυρίως) διαδικασιών. Προκύπτει επομένως και σημαντική προσπάθεια εκπαίδευσης των τελικών χρηστών. Ποιά είναι η πρόβλεψη για αυτό; Μπορεί το Ελληνικό Δημόσιο να εκπαιδεύσει με σύντομο και αποδοτικό τρόπο χιλιάδες γιατρών και φαρμακοποιών;
4. Δεν είναι προφανές από το άρθρο ποιά είναι η επίπτωση της έλλειψης στοιχειώδους απαραίτητης πληροφορίας (π.χ. στοιχεία Μητρώου ασφαλισμένων/συνταξιούχων) ακόμα και από μεγάλα Ασφαλιστικά Ταμεία.
5. Η χρήση ενός κεντρικού συστήματος και μόνο (portal κατά το άρθρο) είναι εξαιρετικά δυσλειτουργική σε περιπτώσεις όπου ο τελικός χρήστης δεν έχει για μικρό ή μεγάλο χρονικό διάστημα πρόσβαση στο σύστημα (π.χ. σε περιπτώσεις που το δίκτυο στο ιατρείο ή στο φαρμακείο δε λειτουργεί για οποιοδήποτε λόγο). Υπάρχουν οι διαδικασίες ώστε κάποιος να μην κλείνει το ιατρείο ή το φαρμακείο του σε περίπτωση που εμφανίζονται τέτοια προβλήματα;
6. Τέλος, το σύστημα που περιγράφεται στο άρθρο, το έχω δει να περιγράφεται αυτούσιο από την περίοδο 2003-2004 με τους ίδιους όρους (portal, κάρτες, κτλ.). Μα από τότε έχουν υπάρξει τόσο διεθνή standards αλλά και αρχιτεκτονικές συστημάτων που μπορούν να χρησιμοποιηθούν σαν οδηγός τόσο για τη λήψη στρατηγικών αποφάσεων όσο και για την τεχνική υλοποίηση ενός τέτοιου έργου.
   

Η διαφαινόμενη έλλειψη πρόβλεψης για τα παραπάνω είναι ο σίγουρος δρόμος για να καταστήσεις ένα σύστημα μη αποδοτικό και επομένως να το θέσεις σε αχρηστία (πιθανά και πριν από το τέλος της πιλοτικής του λειτουργίας).
 
Τι θα μπορούσε να γίνει:

1. Το Κράτος (με την έννοια των ανθρώπων που ασκούν πολιτική εξουσία) να οριοθετήσει το βαθμό εμπλοκής του στην υλοποίηση του συστήματος. Αποψή μας είναι ότι το  λογισμικό (και οι συναφείς υπηρεσίες) που χρησιμοποιούνται από τελικούς χρήστες είναι υπόθεση μη κρατικών φορέων. Η εμπλοκή του Κράτους πρέπει να οριστεί πολιτικά ώστε να εκτείνεται μέχρι:

• Την υλοποίηση του κεντρικού συστήματος παροχής και ελέγχου δεδομένων.
  

• Τη δημοσιοποίηση του πρωτοκόλλου επικοινωνίας με αυτό το κεντρικό σύστημα για την εκτέλεση συναλλαγών.

• Την νομοθέτηση της απαγόρευσης πληρωμών εκτός αυτού του συστήματος.

2. Οι Υπηρεσιακοί Παράγοντες (στελέχη του Δημοσίου σε συνεργασία, ενδεχομένως, με συμβούλους) θα έπρεπε:

• Να προδιαγράψουν με σαφήνεια το διαδικαστικό μέρος (π.χ. τι διαδικασία πρέπει να ακολουθηθεί όταν υπάρχει αδυναμία επικοινωνίας με το κεντρικό σύστημα) και το πρωτόκολλο επικοινωνίας.
• Να θέσουν τους κανόνες πιστοποίησης τρίτων (μη κρατικών) κατασκευαστών λογισμικού σχετικά με το εάν αυτοί είναι σε θέση να  διασυνδέονται με το κεντρικό σύστημα με ασφάλεια και αξιοπιστία.
• Να αξιολογήσουν την ετοιμότητα και να προετοιμάσουν το πλάνο ένταξης κάθε Ταμείου στο σύστημα αυτό.
• Να επιβλέψουν την υλοποίηση του κεντρικού συστήματος.

 3. Η παροχή υπηρεσιών (λογισμικό, εκπαίδευση, υποστήριξη) προς τους τελικούς χρήστες να γίνει από μη κρατικούς φορείς και μόνο. Το απλούστερο σενάριο περιλαμβάνει εταιρείες Πληροφορικής που θα αναπτύξουν λογισμικό που θα υλοποιεί το πρωτόκολλο διενέργειας συναλλαγών και θα παρέχουν τόσο τις άδειες χρήσης του όσο και τις συναφείς υπηρεσίες έναντι π.χ. ετήσιας συνδρομής. Το πιό ακραίο σενάριο θα μπορούσε να περιλαμβάνει τη λειτουργία ενδιάμεσων οργανισμών (clearing houses) που παρέχουν όλες τις υπηρεσίες προς τους τελικούς χρήστες (συμπεριλαμβανομένης της πληρωμής). Στο τελευταίο σενάριο όμως τα νερά γίνονται επικίνδυνα βαθιά και δε θα ήθελα να επεκταθώ άλλο.

Τα οφέλη από μιά τέτοια προσέγγιση θα ήταν πολλαπλά:

1. Συντομότερη κατασκευή του κεντρικού συστήματος με αποτέλεσμα την ταχύτερη επίτευξη του βασικού στόχου που είναι ο έλεγχος δαπανών φαρμακευτικής περίθαλψης. Ταυτόχρονα θα έμπαιναν τα θεμέλια για την έπεκτασή του και σε άλλες περιοχές όπως η νοσοκομειακή περίθαλψη ή ο έλεγχος άλλου τύπου δαπανών (π.χ. συσκευές και βοηθήματα προς αναπήρους, κτλ.).
2. Οι τελικοί χρήστες θα ήταν σε θέση να χρησιμοποιούν πιό παραγωγικά περιβάλλοντα εργασίας. Ενας μη κρατικός φορέας που ενδιαφέρεται να αποκτήσει πελατεία σε αυτό το χώρο θα φρόντιζε να κατασκευάσει λογισμικό που προσθέτει αξία στη δουλειά του επαγγελματία/πελάτη του π.χ. προσφέροντάς του δυνατότητες ακόμη και κατά ειδικότητα ή την εξαγωγή προσωποποιημένων αναφορών σχετικά με τα φάρμακα που χορηγεί.
3. Σε σχέση με τον προβληματισμό που εκφράζεται στο άρθρο σχετικά με την καθυστέρηση έναρξης υλοποίησης του έργου λόγω προστριβών (για να το θέσω κομψά) των υποψήφιων αναδόχων, ο κίνδυνος θα ελαχιστοποιούνταν καθώς όλοι θα είχαν συμφέρον να ανοίξει μιά νέα αγορά και όχι απλώς να πάρουν άλλο ένα έργο που τελικά θα τους «βάλει μέσα».

Επειδή τελικά το κείμενο βγήκε περισσότερο από ότι υπολόγιζα, πριν σταματήσω, παραθέτω και δύο αναφορές που υποστηρίζουν την προσέγγιση που περιέγραψα (ένα απλό search στο Google θα επιστρέψει επαρκείς πληροφορίες και για τα δύο):

1. Η πρώτη αναφορά αφορά το Health Insurance Portability and Accountability Act (HIPAA) που εφαρμόζεται στις ΗΠΑ και περιλαμβάνει (πέραν του νομοθετικού πλαισίου) και ένα συγκεκριμένο πρωτόκολλο επικοινωνίας (επέκταση του πρωτοκόλου HL7) για τη διενέργεια συναλλαγών ασφάλισης.
2. Η δεύτερη σχετίζεται με τον ευρύτερο χώρο της Κοινωνικής Ασφάλισης στην Ευρωπαϊκή Ενωση και αφορά το σύστημα EESSI (Electronic Exchange of Social Security Information) που βρίσκεται σε φάση υλοποίησης.  Η σχετικότητα του συγκεκριμένου έργου έγκειται στην επιλογή τεχνικών αρχιτεκτονικών από την Ευρωπαϊκή Ενωση για την επικοινωνία μεταξύ Φορέων Κοινωνικής Ασφάλισης.  Οι συγκεκριμένες επιλογές πρέπει εντός των επόμενων ετών να υιοθετηθούν και από τους φορείς την Κοινωνικής Ασφάλισης στην Ελλάδα.

Προφανώς και δεν διεκδικώ κανένα αλάθητο και είμαι σίγουρος ότι υπάρχουν και άλλα πρότυπα ή ιδέες που θα μπορούσαν να αναφερθούν ή να μελετηθούν προς υλοποίηση.
Τίποτε όμως δεν είναι πιό σημαντικό από την λήψη μιάς κατ’αρχήν ΠΟΛΙΤΙΚΗΣ απόφασης που ανοίγει το δρόμο σε επαγγελματίες (του Δημόσιου και Ιδιωτικού Τομέα) ώστε να δουλέψουν πάνω σε συγκεκριμένα θέματα. Και τέτοιες πολιτικές αποφάσεις δεν φαίνεται να παίρνει κανείς...