Σύντομη απάντηση: Το SMART App Launch (SMART on FHIR) είναι η προδιαγραφή του HL7 για το πώς μια εφαρμογή αποκτά εξουσιοδοτημένη πρόσβαση σε έναν FHIR server για λογαριασμό ενός χρήστη. Είναι OAuth 2.0 και OpenID Connect με συμβάσεις ειδικές για το FHIR: ένα έγγραφο ανακάλυψης στο .well-known/smart-configuration; δύο τρόποι εκκίνησης (εκκίνηση EHR, όπου το EHR ανοίγει την εφαρμογή στο πλαίσιο του τρέχοντος ασθενούς, και αυτόνομη εκκίνηση, όπου ο χρήστης ανοίγει την εφαρμογή και επιλέγει έναν ασθενή). Πεδία εμβέλειας σε σύνταξη κατανοητή από το FHIR (patient/Observation.rs σημαίνει ανάγνωση και αναζήτηση Παρατηρήσεων του ασθενούς στο πλαίσιο). Πλαίσιο εκκίνησης που επιστρέφεται με το token (ποιος ασθενής, ποια συνάντηση). και υπηρεσίες παρασκηνίου για πρόσβαση από σύστημα σε σύστημα με υπογεγραμμένη επαλήθευση ταυτότητας πελάτη JWT. Το SMART v2 (από το 2021) κατέστησε το PKCE υποχρεωτικό, πρόσθεσε λεπτομερή πεδία εμβέλειας και ασύμμετρη επαλήθευση ταυτότητας πελάτη, και είναι η έκδοση που απαιτούν τα εθνικά προγράμματα.
Βήμα 1: Ανακάλυψη
Η ανακάλυψη του SMART App Launch ξεκινά με την εφαρμογή να ανακτά το έγγραφο .well-known/smart-configuration του διακομιστή FHIR. Αυτό το έγγραφο παραθέτει τα τελικά σημεία εξουσιοδότησης και token, τις υποστηριζόμενες δυνατότητες (εκκίνηση EHR, αυτόνομη εκκίνηση, δημόσιοι και εμπιστευτικοί πελάτες, OpenID Connect, δικαιώματα ασθενούς και χρήστη), τα υποστηριζόμενα πεδία εμβέλειας (scopes), τις μεθόδους πρόκλησης κώδικα PKCE και τους τύπους παραχώρησης. Έτσι, η εφαρμογή γνωρίζει πού να στείλει τον χρήστη.
GET https://fhir.example-hospital.org/.well-known/smart-configuration
{
"issuer": "https://auth.example-hospital.org",
"authorization_endpoint": "https://auth.example-hospital.org/authorize",
"token_endpoint": "https://auth.example-hospital.org/token",
"introspection_endpoint": "https://auth.example-hospital.org/introspect",
"capabilities": ["launch-ehr", "launch-standalone", "client-public", "client-confidential-asymmetric", "sso-openid-connect", "context-ehr-patient", "context-standalone-patient", "permission-patient", "permission-user", "permission-v2", "permission-offline"],
"scopes_supported": ["openid", "fhirUser", "launch", "launch/patient", "patient/*.rs", "user/*.rs", "offline_access"],
"code_challenge_methods_supported": ["S256"],
"grant_types_supported": ["authorization_code", "client_credentials"]
}
Η εφαρμογή μαθαίνει πού να στείλει τον χρήστη και τι υποστηρίζει ο διακομιστής.
Βήμα 2: Εκκίνηση
Το SMART App Launch έχει δύο τρόπους εκκίνησης. Σε μια εκκίνηση EHR, ο κλινικός γιατρός ανοίγει την εφαρμογή μέσα στο EHR, το οποίο περνά μια παράμετρο iss (ο διακομιστής FHIR) και ένα αδιαφανές token εκκίνησης που κωδικοποιεί τον τρέχοντα ασθενή και την επίσκεψη. Σε μια αυτόνομη εκκίνηση, ο χρήστης ανοίγει την εφαρμογή απευθείας και ο διακομιστής εξουσιοδότησης του ζητά να επιλέξει ή να επιβεβαιώσει έναν ασθενή.
Εκκίνηση EHR. Ο κλινικός ιατρός κάνει κλικ στην εφαρμογή μέσα στο EHR. Το EHR ανοίγει τη διεύθυνση URL εκκίνησης της εφαρμογής με δύο παραμέτρους: iss (ο FHIR server) και launch (ένα αδιαφανές token που κωδικοποιεί τον τρέχοντα ασθενή και τη συνάντηση). Η εφαρμογή πρέπει να επαναλάβει το launch στο αίτημα εξουσιοδότησής της με το πεδίο εμβέλειας launch.
Αυτόνομη εκκίνηση. Ο χρήστης ανοίγει την εφαρμογή απευθείας. Η εφαρμογή γνωρίζει τον FHIR server (επιλεγμένο ή διαμορφωμένο) και ζητά πλαίσιο με launch/patient. Ο διακομιστής εξουσιοδότησης ζητά από τον χρήστη να επιλέξει ή να επιβεβαιώσει έναν ασθενή.
Βήμα 3: Κωδικός εξουσιοδότησης με PKCE
Το βήμα εξουσιοδότησης SMART είναι η ροή κώδικα εξουσιοδότησης OAuth 2.0 με PKCE: η εφαρμογή στέλνει τον χρήστη στο τελικό σημείο εξουσιοδότησης με τα πεδία εμβέλειάς της, το aud του διακομιστή FHIR και μια πρόκληση κώδικα. Ο χρήστης πιστοποιείται και εγκρίνει. Η εφαρμογή ανταλλάσσει τον κωδικό που επιστρέφεται και τον επαληθευτή κώδικα για ένα token πρόσβασης που φτάνει μαζί με το πλαίσιο εκκίνησης.
GET https://auth.example-hospital.org/authorize?
response_type=code&client_id=my-app&redirect_uri=https://app.example.org/cb
&scope=openid%20fhirUser%20launch%20patient/Observation.rs%20patient/Condition.rs%20offline_access
&state=af0ifjsldkj&aud=https://fhir.example-hospital.org
&launch=xyz123&code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM&code_challenge_method=S256
Ο χρήστης πιστοποιείται (με τον πάροχο ταυτότητας του νοσοκομείου) και εγκρίνει τα πεδία εμβέλειας. Ο διακομιστής ανακατευθύνει πίσω με έναν code. Η εφαρμογή τον ανταλλάσσει:
POST https://auth.example-hospital.org/token
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&code=...&redirect_uri=https://app.example.org/cb&client_id=my-app&code_verifier=dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
{
"access_token": "eyJhbGciOi...",
"token_type": "Bearer",
"expires_in": 3600,
"scope": "openid fhirUser launch patient/Observation.rs patient/Condition.rs offline_access",
"refresh_token": "a8c3...",
"id_token": "eyJhbGciOi...",
"patient": "Patient/123",
"encounter": "Encounter/456",
"fhirUser": "Practitioner/42",
"need_patient_banner": true,
"smart_style_url": "https://ehr.example.org/styles/smart.json"
}
Το πλαίσιο εκκίνησης (patient, encounter, fhirUser) φτάνει μαζί με το token. Οι δημόσιοι πελάτες (εφαρμογές κινητών και προγράμματος περιήγησης) χρησιμοποιούν PKCE και κανένα μυστικό πελάτη. Οι εμπιστευτικοί πελάτες πιστοποιούνται με ένα μυστικό ή, κατά προτίμηση, με ένα υπογεγραμμένο JWT (private_key_jwt) με την ασύμμετρη μέθοδο.
Πεδία Εμβέλειας
Τα πεδία εμβέλειας (scopes) του SMART on FHIR v2 χρησιμοποιούν τη σύνταξη context/resource.permissions, όπου το context είναι patient, user ή system και τα permissions συνδυάζουν c, r, u, d και s για create (δημιουργία), read (ανάγνωση), update (ενημέρωση), delete (διαγραφή) και search (αναζήτηση), όπως στο patient/Observation.rs. Τα λεπτομερή πεδία εμβέλειας προσθέτουν ένα φίλτρο, τα openid και fhirUser δίνουν την ταυτότητα του χρήστη, τα πεδία εμβέλειας launch ζητούν πλαίσιο και το offline_access ζητά ένα token ανανέωσης.
Σύνταξη SMART v2: <context>/<resource>.<permissions> όπου το context είναι patient (ο ασθενής στο πλαίσιο), user (ό,τι μπορεί να δει ο χρήστης) ή system (παρασκήνιο), και οι άδειες είναι οποιαδήποτε από c δημιουργία, r ανάγνωση, u ενημέρωση, d διαγραφή, s αναζήτηση, με αυτή τη σειρά: patient/Observation.rs, user/Patient.rs, system/*.cruds. Λεπτομερή πεδία εμβέλειας προσθέτουν ένα φίλτρο: patient/Observation.rs?category=http://terminology.hl7.org/CodeSystem/observation-category|vital-signs. Τα openid fhirUser δίνουν ένα ID token και την ταυτότητα FHIR του χρήστη. Τα launch, launch/patient, launch/encounter ζητούν πλαίσιο. Το offline_access ένα refresh token για χρήση όταν ο χρήστης απουσιάζει, το online_access ένα που ισχύει μόνο κατά τη διάρκεια της συνεδρίας. Η σύνταξη v1 (patient/Observation.read) εξακολουθεί να γίνεται αποδεκτή από πολλούς διακομιστές.
Υπηρεσίες Παρασκηνίου
Για ένα σύστημα που λειτουργεί χωρίς χρήστη (μια νυχτερινή εξαγωγή, μια μηχανή ενσωμάτωσης), το SMART Backend Services χρησιμοποιεί client_credentials με μια υπογεγραμμένη δήλωση JWT (τα δημόσια κλειδιά του πελάτη δημοσιεύονται σε μια διεύθυνση URL JWKS) και πεδία εμβέλειας system/. Χωρίς χρήστη, χωρίς πλαίσιο εκκίνησης, αυστηρή εγγραφή.
Εκτέλεση με ασφάλεια
Η ασφαλής εκτέλεση του SMART App Launch σημαίνει την καταχώρηση ακριβών διευθύνσεων URL ανακατεύθυνσης, τη μη χρήση της σιωπηρής ροής (implicit flow), την ασφαλή αποθήκευση και εναλλαγή των tokens ανανέωσης, την επικύρωση της κατάστασης (state) και του aud των ID tokens, την επαλήθευση των tokens σε κάθε κλήση API, την επιβολή τόσο των πεδίων εμβέλειας όσο και του πλαισίου του ασθενούς στο επίπεδο δεδομένων, ώστε ένα token για έναν ασθενή να μην διαβάζει ποτέ δεδομένα άλλου, και την καταγραφή κάθε πρόσβασης.
Καταχωρήστε ακριβείς διευθύνσεις URL ανακατεύθυνσης. μην χρησιμοποιείτε ποτέ τη ροή implicit. αποθηκεύστε με ασφάλεια τα refresh tokens και περιστρέψτε τα. επαληθεύστε το state. ελέγξτε το aud των ID tokens. επαληθεύστε τα tokens σε κάθε κλήση API (introspection ή επαλήθευση JWT) και επιβάλετε τα πεδία εμβέλειας και το πλαίσιο του ασθενούς στο επίπεδο δεδομένων, επειδή ένα token για Patient/123 δεν πρέπει ποτέ να διαβάζει Patient/124. καταγράψτε κάθε πρόσβαση (Ασφάλεια και ταυτότητα: ο χάρτης). Το SMART ορίζει επίσης Patient Access Brands, έναν τρόπο για τις εφαρμογές να δείχνουν στους χρήστες με ποιους οργανισμούς μπορούν να συνδεθούν, και συνεργάζεται με το SMART Health Links για κοινή χρήση κατόπιν πρωτοβουλίας του ασθενούς.
Πού απαιτείται
Οι κανόνες πρόσβασης ασθενών στις ΗΠΑ απαιτούν από τα πιστοποιημένα EHR να υποστηρίζουν SMART App Launch και Backend Services. Τα εθνικά προγράμματα στην Ευρώπη το υιοθετούν για πρόσβαση σε εφαρμογές (το MedMij της Ολλανδίας χρησιμοποιεί OAuth 2.0 με ισοδύναμες συμβάσεις). Το IPS και πολλοί οδηγοί υλοποίησης το υποθέτουν. Δείτε TEFCA και Εθνικά ηλεκτρονικά αρχεία υγείας.
Στο Anpheros
Η πλατφόρμα Anpheros χρησιμοποιεί OAuth 2.0 με PKCE για εφαρμογές και επαλήθευση ταυτότητας πελάτη με υπογεγραμμένο JWT για παρασκήνια, με πεδία εμβέλειας που προέρχονται από τη συγκατάθεση του ατόμου και το πλαίσιο του ασθενούς που επιβάλλεται σε κάθε αίτημα. Ο ιστότοπος προγραμματιστών τεκμηριώνει την επαλήθευση ταυτότητας και το πρότυπο SMART on FHIR backend για τη δημιουργία πάνω σε αυτό.
Σχετικές σελίδες
- Ασφάλεια και ταυτότητα σε εφαρμογές υγείας: ο χάρτης
- Πλατφόρμα συγκατάθεσης ασθενούς
- Επεξήγηση SMART Health Links
- Επεξήγηση CDS Hooks
- Επεξήγηση αναζήτησης FHIR
- SMART on FHIR backend (ιστότοπος προγραμματιστών)
- Επαλήθευση ταυτότητας (ιστότοπος προγραμματιστών)
Πηγές
- HL7 SMART App Launch (STU 2.2)
- HL7 SMART App Launch: πεδία εμβέλειας και πλαίσιο εκκίνησης
- HL7 SMART App Launch: Υπηρεσίες Παρασκηνίου
- IETF RFC 7636: PKCE
- IETF RFC 6749: OAuth 2.0
- OpenID Connect Core 1.0
Συχνές ερωτήσεις
Είναι το SMART on FHIR το ίδιο με το OAuth 2.0;
Είναι OAuth 2.0 και OpenID Connect με προσθήκες ειδικές για το FHIR: ανακάλυψη, πλαίσιο εκκίνησης, σύνταξη πεδίου εμβέλειας και υπηρεσίες παρασκηνίου. Οποιαδήποτε βιβλιοθήκη OAuth λειτουργεί. Οι συμβάσεις SMART είναι αυτές που καθιστούν μια εφαρμογή φορητή μεταξύ FHIR servers.
Χρειάζομαι PKCE για μια εφαρμογή server-side;
Στο SMART v2, ναι, για όλους τους πελάτες που χρησιμοποιούν τη ροή κωδικού εξουσιοδότησης. Οι εμπιστευτικοί πελάτες προσθέτουν επαλήθευση ταυτότητας πελάτη (μυστικό ή υπογεγραμμένο JWT) από πάνω.
Ποια είναι η διαφορά μεταξύ των πεδίων εμβέλειας patient/ και user/;
Το patient/ περιορίζει την πρόσβαση στον μοναδικό ασθενή στο πλαίσιο εκκίνησης. Το user/ χορηγεί ό,τι ο πιστοποιημένος χρήστης επιτρέπεται να δει, ανεξαρτήτως ασθενών. Οι εφαρμογές που απευθύνονται σε ασθενείς χρησιμοποιούν patient/. Οι εφαρμογές κλινικών ιατρών συχνά χρησιμοποιούν user/ με πλαίσιο.
Μπορεί μια εφαρμογή SMART να γράψει στο αρχείο;
Εάν της έχουν χορηγηθεί άδειες δημιουργίας ή ενημέρωσης (c, u) στα πεδία εμβέλειάς της και ο διακομιστής το επιτρέπει. Πολλές αναπτύξεις χορηγούν στις εφαρμογές ασθενών μόνο ανάγνωση και αναζήτηση, και δρομολογούν τις εγγραφές μέσω συγκεκριμένων πόρων όπως το QuestionnaireResponse.
Δοκιμάστε δωρεάν στο sandbox
Η πρώτη σας κλήση FHIR σε 5 λεπτά. Ένα API HL7 FHIR R4 με τη συγκατάθεση του ασθενούς ενσωματωμένη: δοκιμάστε το στο sandbox, στη συνέχεια συνδέστε τη δική σας εφαρμογή ή σύστημα κλινικής.
Δωρεάν · 30 συνθετικοί ασθενείς · χωρίς κάρτα
Το Anpheros δημιουργεί ένα ιατρικό αρχείο που ελέγχει ο ασθενής και μπορεί να μοιραστεί με οποιαδήποτε κλινική, σε πλατφόρμα HL7 FHIR R4, με έδρα την ΕΕ. Αυτοί οι οδηγοί σάς βοηθούν να κατανοήσετε και να οργανώσετε την υγεία σας· δεν αντικαθιστούν τον γιατρό σας.
Σχετικά με το Anpheros →