Ασφάλεια και ταυτότητα σε εφαρμογές υγείας: ο χάρτης

Σύντομη απάντηση: η ασφάλεια σε μια εφαρμογή υγείας απαντά σε τέσσερις ερωτήσεις, με τη σειρά. Ποιος είναι αυτός; Ταυτότητα: ένας επαληθευμένος χρήστης (ασθενής, κλινικός ιατρός, σύστημα) μέσω OpenID Connect και, για τους κλινικούς ιατρούς, η εθνική επαγγελματική ταυτότητα· το επίπεδο επαλήθευσης έχει μεγαλύτερη σημασία από την ισχύ του κωδικού πρόσβασης. Τι μπορεί να κάνει; Εξουσιοδότηση: διακριτικά OAuth 2.0 (μετάβαση στο 2.1) με πεδία εφαρμογής (scopes) στη σύνταξη SMART on FHIR, που προέρχονται από τη συγκατάθεση του ασθενούς για έναν σκοπό και μια διάρκεια, επιβαλλόμενα στο επίπεδο των δεδομένων. Τι έκανε; Λογοδοσία: ένα αρχείο καταγραφής πρόσβασης που μπορεί να διαβάσει ο ασθενής και ένα μονοπάτι AuditEvent του FHIR για τον οργανισμό. Είναι τα δεδομένα ασφαλή κατά την αποθήκευση, τη μεταφορά και στα αντίγραφα ασφαλείας; Προστασία: κρυπτογράφηση, διαχείριση κλειδιών, διαχωρισμός, δοκιμασμένες επαναφορές. Γύρω τους: η βάση των ISO 27001 και 27799, οι NIS2 και ο Κανόνας Ασφαλείας της HIPAA, και οι ειδικές απειλές των δεδομένων υγείας (εσωτερική περιήγηση, λανθασμένη αρχειοθέτηση, ransomware).

Ο χάρτης

Η ασφάλεια και η ταυτότητα σε μια εφαρμογή υγείας αποτελούνται από επτά επίπεδα: ταυτότητα μέσω OpenID Connect και εθνικών ή επαγγελματικών ταυτοτήτων, εξουσιοδότηση μέσω OAuth 2.0 και πεδίων εφαρμογής SMART on FHIR, συγκατάθεση ως πηγή κάθε άδειας, λογοδοσία μέσω αρχείων καταγραφής πρόσβασης και FHIR AuditEvent, προστασία μέσω κρυπτογράφησης και αντιγράφων ασφαλείας, μια βασική γραμμή ISO 27001, ISO 27799, NIS2 και HIPAA, και κοινή χρήση κατόπιν πρωτοβουλίας του ασθενούς.

Επίπεδο	Πρότυπο ή πρακτική	Τι σας προσφέρει	Σελίδα
Ταυτότητα	OpenID Connect· εθνικές ταυτότητες (eIDAS, NHS login, GesundheitsID)· επαγγελματικές ταυτότητες (eHBA, CPS, UZI)	Ένα επαληθευμένο υποκείμενο με επίπεδο διασφάλισης	Επεξήγηση SMART App Launch
Εξουσιοδότηση	OAuth 2.0 και 2.1 (PKCE υποχρεωτικό, χωρίς implicit ή password grants)· πεδία εφαρμογής SMART on FHIR (patient/Observation.rs)· υπηρεσίες backend με ασύμμετρη πιστοποίηση πελάτη	Διακριτικά συνδεδεμένα με έναν χρήστη, ένα πλαίσιο ασθενούς και ένα πεδίο εφαρμογής	Επεξήγηση SMART App Launch, Υπηρεσία backend SMART on FHIR
Συγκατάθεση	FHIR Consent· χορηγίες δεσμευμένες από σκοπό και χρόνο· ανάκληση· "break-the-glass" με αιτιολόγηση και ειδοποίηση	Ο ασθενής ως πηγή κάθε εξουσιοδότησης	Πλατφόρμα συγκατάθεσης ασθενούς, Αιτήματα πρόσβασης κλινικής
Λογοδοσία	Αρχεία καταγραφής πρόσβασης ανά εγγραφή ορατά στον ασθενή· FHIR AuditEvent· αποθήκευση ανθεκτική σε παραποίηση· διατήρηση	Ποιος είδε τι, πότε, γιατί	Ποιος είδε τον ιατρικό μου φάκελο;
Προστασία	TLS 1.2+, κρυπτογράφηση κατά την αποθήκευση με διαχειριζόμενα κλειδιά, κρυπτογράφηση σε επίπεδο πεδίου για αναγνωριστικά, διαχωρισμένα περιβάλλοντα, αντίγραφα ασφαλείας με δοκιμασμένη επαναφορά	Εμπιστευτικότητα και διαθεσιμότητα	ISO 27001 vs ISO 27799
Βάση	ISMS ISO 27001, έλεγχοι υγείας ISO 27799, μέτρα NIS2, Κανόνας Ασφαλείας HIPAA, εθνικά σχήματα (HDS, DSPT, C5)	Τι περιμένουν τα νοσοκομεία, οι ελεγκτές και οι ρυθμιστικές αρχές	NIS2 για νοσοκομεία και προμηθευτές, HIPAA vs GDPR
Κοινή χρήση	SMART Health Links και Cards· επαληθεύσιμα διαπιστευτήρια	Κοινή χρήση που ξεκινά από τον ασθενή με σύνδεσμο ή QR, ανακλητή	Επεξήγηση SMART Health Links

Ταυτότητα: διασφάλιση έναντι κωδικών πρόσβασης

Η ταυτότητα σε μια εφαρμογή υγείας βασίζεται στην επαλήθευση και όχι στην ισχύ του κωδικού πρόσβασης: επίπεδα επαλήθευσης ταυτότητας όπως το NIST IAL, το eIDAS substantial και high, ή το NHS login P9 περιγράφουν πόσο ισχυρά επαληθεύτηκε ένα άτομο κατά την εγγραφή, ενώ ο έλεγχος ταυτότητας πολλών παραγόντων και οι κωδικοί πρόσβασης περιγράφουν κάθε σύνδεση. Οι κλινικοί ιατροί αναγνωρίζονται μέσω επαγγελματικών ταυτοτήτων που ανακαλούνται όταν αποχωρούν.

Μια εφαρμογή ασθενούς που εμφανίζει ένα πλήρες αρχείο πρέπει να γνωρίζει ότι επικοινωνεί με αυτόν τον ασθενή. Τα επίπεδα διασφάλισης ταυτότητας (IAL της NIST, ουσιαστικό και υψηλό επίπεδο eIDAS, NHS login P9) περιγράφουν πόσο ισχυρά επαληθεύτηκε η ταυτότητα κατά την εγγραφή· η ισχύς της πιστοποίησης (πολυπαραγοντική, passkeys) περιγράφει κάθε σύνδεση. Τα νοσοκομεία και τα εθνικά συστήματα απαιτούν όλο και περισσότερο επαληθευμένες ταυτότητες από αναγνωρισμένα σχήματα αντί για αυτο-δηλωμένες εγγραφές, και το Ευρωπαϊκό Ψηφιακό Πορτοφόλι Ταυτότητας θα γίνει αποδεκτό μέσο. Για τους κλινικούς ιατρούς, η επαγγελματική ταυτότητα (και η ανάκλησή της όταν κάποιος αποχωρεί) είναι το σύστημα καταγραφής για το ποιος μπορεί να ενεργεί ως κλινικός ιατρός γενικά.

Εξουσιοδότηση: η συγκατάθεση γίνεται πεδία εφαρμογής

Η εξουσιοδότηση σε ένα αρχείο που ελέγχεται από τον ασθενή μεταφράζει τη συγκατάθεση του ασθενούς, όπως η άδεια σε μια κλινική να διαβάζει εργαστηριακά αποτελέσματα και καταστάσεις για 90 ημέρες, σε πεδία εφαρμογής OAuth και πλαίσιο ασθενούς στο token, σε σύνταξη SMART on FHIR όπως patient/Observation.rs, επιβαλλόμενη στο επίπεδο δεδομένων σε κάθε αίτημα και ανακαλούμενη όταν ο ασθενής αποσύρει τη συγκατάθεσή του. Το "Break-the-glass" είναι μια ξεχωριστή, ελεγμένη διαδρομή.

Σε ένα αρχείο που ελέγχεται από τον ασθενή, η συγκατάθεση του ασθενούς είναι η πολιτική: αυτή η κλινική μπορεί να διαβάσει τα εργαστηριακά μου αποτελέσματα και τις καταστάσεις μου για 90 ημέρες. Το σύστημα το μεταφράζει σε πεδία εφαρμογής OAuth και πλαίσιο (ποιος ασθενής, ποιοι πόροι, ποιες λειτουργίες) στο διακριτικό που λαμβάνει το σύστημα της κλινικής, τα επιβάλλει σε κάθε αίτημα στο επίπεδο των δεδομένων και τα ανακαλεί όταν ο ασθενής αποσύρει τη συγκατάθεση. Η σύνταξη πεδίων εφαρμογής του SMART on FHIR (patient/Observation.rs, patient/Condition.rs) είναι η κοινή γλώσσα για αυτό· υπάρχουν λεπτομερή πεδία εφαρμογής (ανά κατηγορία ή κωδικό) στο SMART v2 για λεπτότερο έλεγχο. Η "break-the-glass" (επείγουσα πρόσβαση χωρίς συγκατάθεση) είναι μια ξεχωριστή, καταγεγραμμένη διαδρομή με υποχρεωτική αιτιολόγηση και ειδοποίηση στον ασθενή, ποτέ προεπιλογή. Δείτε Πλατφόρμα συγκατάθεσης ασθενούς.

Λογοδοσία: το αρχείο καταγραφής που διαβάζει ο ασθενής

Η λογοδοσία σε μια εφαρμογή υγείας σημαίνει ότι κάθε πρόσβαση σε ένα αρχείο, από ποιον, πότε, τι και υπό ποια συγκατάθεση, καταγράφεται σε ένα αρχείο καταγραφής μόνο για προσθήκη που ο ασθενής μπορεί να διαβάσει στην εφαρμογή του και σε ένα οργανωτικό αρχείο καταγραφής ελέγχου στο FHIR AuditEvent. Το ISO 27799 αντιμετωπίζει αυτό ως υποχρεωτικό, και ένα ορατό αρχείο καταγραφής είναι το ισχυρότερο αποτρεπτικό μέσο για την περιήγηση από εσωτερικούς χρήστες.

Κάθε πρόσβαση σε ένα αρχείο, από ποιον, πότε, τι, υπό ποια συγκατάθεση, εγγράφεται σε ένα αρχείο καταγραφής μόνο προσθήκης που ο ασθενής μπορεί να διαβάσει στην εφαρμογή του, και σε ένα οργανωτικό μονοπάτι ελέγχου (FHIR AuditEvent) για τις ομάδες ασφαλείας. Το ISO 27799 το αντιμετωπίζει ως υποχρεωτικό για πληροφορίες υγείας· η αρχή της διαφάνειας του GDPR και τα δικαιώματα των ασθενών του EHDS δείχνουν προς την ίδια κατεύθυνση· το μεγαλύτερο πραγματικό αποτρεπτικό μέσο για την εσωτερική περιήγηση είναι ένα ορατό αρχείο καταγραφής. Δείτε Ποιος είδε τον ιατρικό μου φάκελο;.

Προστασία: η μηχανική βάση

Η μηχανική βάση για την προστασία δεδομένων υγείας είναι το TLS παντού, η κρυπτογράφηση κατά την αποθήκευση με διαχειριζόμενα, εναλλασσόμενα κλειδιά, ξεχωριστή κρυπτογράφηση ή κωδικοποίηση για άμεσους αναγνωριστικούς παράγοντες, διαχωρισμένα περιβάλλοντα με συνθετικά δεδομένα εκτός παραγωγής, πρόσβαση με ελάχιστα προνόμια με έλεγχο ταυτότητας πολλών παραγόντων για διαχειριστές, διαχείριση μυστικών και ευπαθειών, κρυπτογραφημένα αντίγραφα ασφαλείας που ελέγχονται με επαναφορά έναντι ransomware, και απόκριση σε περιστατικά εντός των χρονικών πλαισίων του GDPR και του NIS2.

TLS παντού, με σύγχρονα κρυπτογραφικά αλγόριθμους και καρφίτσωμα πιστοποιητικών σε εφαρμογές όπου είναι κατάλληλο· κρυπτογράφηση κατά την αποθήκευση με κλειδιά σε μια διαχειριζόμενη υπηρεσία κλειδιών και περιστροφή· ξεχωριστή κρυπτογράφηση ή ανωνυμοποίηση για άμεσα αναγνωριστικά· διαχωρισμός παραγωγής από ανάπτυξη, με συνθετικά δεδομένα εκτός παραγωγής· πρόσβαση με ελάχιστα προνόμια για το προσωπικό, χωρίς κοινούς λογαριασμούς, πολυπαραγοντική πιστοποίηση για όλη την διοικητική πρόσβαση· διαχείριση μυστικών· διαχείριση εξαρτήσεων και ευπαθειών με δημοσιοποίηση· αντίγραφα ασφαλείας κρυπτογραφημένα, δοκιμασμένα με επαναφορά, και προστατευμένα από το ransomware που έχει πλήξει νοσοκομεία και εργαστήρια επανειλημμένα (WannaCry το 2017, το νοσοκομείο του Ντίσελντορφ το 2020, Change Healthcare και Synnovis το 2024). Αντιμετώπιση περιστατικών με τα χρονόμετρα 72 ωρών του GDPR και 24 ωρών του NIS2 σε ένα μόνο σχέδιο δράσης.

Απειλές ειδικές για δεδομένα υγείας

Οι απειλές που είναι ειδικές για τα δεδομένα υγείας είναι η περιήγηση από εσωτερικούς χρήστες στα αρχεία γνωστών, η λανθασμένη αρχειοθέτηση μεταξύ ασθενών, η υπερβολικά ευρεία κοινή χρήση που χορηγείται για πολύ μεγάλο χρονικό διάστημα, τα SDK διαφημίσεων εντός εφαρμογών που χειρίζονται δεδομένα υγείας, η εισαγωγή μέσω εγγράφων σε λειτουργίες AI και η μακρά διατήρηση για δεκαετίες κατά τη διάρκεια των οποίων τα κλειδιά, οι μορφές και οι κανόνες πρόσβασης πρέπει να επιβιώνουν από το προσωπικό και τους προμηθευτές.

Εσωτερική περιήγηση αρχείων γνωστών ή δημόσιων προσώπων: πρόσβαση βάσει σχέσης και ορατά αρχεία καταγραφής.
Λανθασμένη αρχειοθέτηση μεταξύ ασθενών: αντιστοίχιση ταυτότητας και προέλευση, όχι μόνο έλεγχος πρόσβασης.
Υπερβολικά ευρεία κοινή χρήση: μια κλινική που έλαβε "τα πάντα" για ένα χρόνο· πεδία εφαρμογής και διάρκειες με λογικές προεπιλογές.
Εφαρμογές με SDK διαφημίσεων: κανένας ιχνηλάτης τρίτων σε οτιδήποτε χειρίζεται δεδομένα υγείας.
Έγχυση μέσω εγγράφων σε λειτουργίες AI: το περιεχόμενο είναι δεδομένα, ποτέ οδηγίες (RAG σε ιατρικούς φακέλους).
Μεγάλη διατήρηση: τα αρχεία ζουν για δεκαετίες· τα κλειδιά, οι μορφές και οι κανόνες πρόσβασης πρέπει να επιβιώσουν του προσωπικού και των προμηθευτών.

Στην Anpheros

Η Anpheros εφαρμόζει τον χάρτη ασφαλείας στον εαυτό της με OAuth 2.0 με PKCE για εφαρμογές και ασύμμετρη πιστοποίηση πελάτη για backends, συγκατάθεση ανά σκοπό και διάρκεια ως πηγή πρόσβασης κάθε κλινικής, αρχείο καταγραφής πρόσβασης ανά εγγραφή στην εφαρμογή του ατόμου, κρυπτογράφηση κατά την αποθήκευση και κατά τη μεταφορά, φιλοξενία στην ΕΕ, χωρίς SDK διαφημίσεων και ένα ISMS σύμφωνα με τα πρότυπα ISO 27001 και 27799.

Η Anpheros εφαρμόζει αυτόν τον χάρτη στον εαυτό της: OAuth 2.0 με PKCE για εφαρμογές και ασύμμετρη πιστοποίηση πελάτη για backend· συγκατάθεση ανά σκοπό και διάρκεια ως πηγή πρόσβασης κάθε κλινικής, με ανάκληση και χωρίς σιωπηλή "break-the-glass"· ένα αρχείο καταγραφής πρόσβασης ανά εγγραφή στην εφαρμογή του ατόμου· κρυπτογράφηση κατά την αποθήκευση και τη μεταφορά, φιλοξενία στην ΕΕ, κανένα SDK διαφημίσεων· ένα ISMS σύμφωνα με το ISO 27001 με τους ελέγχους υγείας ISO 27799. Ο ιστότοπος προγραμματιστών τεκμηριώνει πιστοποίηση, συγκατάθεση και ασφάλεια.

Σχετικές σελίδες

Πηγές

Συχνές ερωτήσεις

Είναι το OAuth 2.1 διαφορετικό από το 2.0;

Το OAuth 2.1 ενοποιεί το 2.0 με τις βέλτιστες πρακτικές ασφαλείας του: το PKCE είναι υποχρεωτικό για όλους τους πελάτες, οι implicit και password grants καταργούνται, τα redirect URIs πρέπει να ταιριάζουν ακριβώς, και τα refresh tokens για δημόσιους πελάτες πρέπει να είναι δεσμευμένα ή να περιστρέφονται. Το SMART on FHIR v2 απαιτεί ήδη τα περισσότερα από αυτά.

Τι είναι το "break-the-glass";

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

Γιατί οι ασθενείς πρέπει να βλέπουν το αρχείο καταγραφής πρόσβασης;

Επειδή είναι το ισχυρότερο αποτρεπτικό μέσο για ακατάλληλη πρόσβαση και η σαφέστερη έκφραση ελέγχου: το άτομο βλέπει ποια κλινική διάβασε τι και πότε, και μπορεί να ανακαλέσει. Το ISO 27799 και το EHDS δείχνουν προς την ίδια κατεύθυνση.

Χρειάζομαι ξεχωριστό σύστημα ελέγχου;

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

Anpheros Platform

Δοκιμάστε δωρεάν στο sandbox

Η πρώτη σας κλήση FHIR σε 5 λεπτά. Ένα API HL7 FHIR R4 με τη συγκατάθεση του ασθενούς ενσωματωμένη: δοκιμάστε το στο sandbox, στη συνέχεια συνδέστε τη δική σας εφαρμογή ή σύστημα κλινικής.

Δημιουργία δωρεάν sandbox Διαβάστε τους οδηγούς προγραμματιστών →

Δωρεάν · 30 συνθετικοί ασθενείς · χωρίς κάρτα

Αυτός ο οδηγός παρέχεται για ενημερωτικούς σκοπούς και δεν αντικαθιστά την ιατρική συμβουλή. Για αποφάσεις σχετικά με την υγεία σας, μιλήστε με τον γιατρό σας. Σε επείγουσα περίπτωση, καλέστε τον τοπικό αριθμό έκτακτης ανάγκης (112 στην Ευρώπη).

Συντάχθηκε από

Η ομάδα του Anpheros

Το Anpheros δημιουργεί ένα ιατρικό αρχείο που ελέγχει ο ασθενής και μπορεί να μοιραστεί με οποιαδήποτε κλινική, σε πλατφόρμα HL7 FHIR R4, με έδρα την ΕΕ. Αυτοί οι οδηγοί σάς βοηθούν να κατανοήσετε και να οργανώσετε την υγεία σας· δεν αντικαθιστούν τον γιατρό σας.

Σχετικά με το Anpheros →