सुरक्षा

SMART ऐप लॉन्च को समझें: स्कोप, लॉन्च कॉन्टेक्स्ट, PKCE और पेशेंट-फ़्लो

SMART ऐप लॉन्च HL7 स्पेसिफ़िकेशन है जो किसी भी FHIR सर्वर पर यूज़र की अनुमति से ऐप चलाने की सुविधा देता है: डिस्कवरी, EHR और स्टैंडअलोन लॉन्च, PKCE के साथ ऑथराइज़ेशन कोड फ़्लो, स्कोप सिंटैक्स, लॉन्च कॉन्टेक्स्ट, रिफ़्रेश टोकन, बैकएंड सर्विस और SMART v2 में क्या बदला है, असली रिक्वेस्ट के साथ।

Anpheros द्वारा लिखा गया, स्रोतों सहित
जानकारी, चिकित्सा सलाह नहीं
डेटा EU में संग्रहीत

द्वारा Anpheros प्रकाशित 26 अक्टूबर 2026 7 मिनट पढ़ें

संक्षिप्त उत्तर: SMART App Launch (SMART on FHIR) HL7 का वह स्पेसिफिकेशन है जो बताता है कि किसी ऐप को उपयोगकर्ता की ओर से FHIR सर्वर तक अधिकृत पहुँच कैसे मिलती है। यह OAuth 2.0 और OpenID Connect है जिसमें FHIR-विशिष्ट परंपराएँ हैं: .well-known/smart-configuration पर एक डिस्कवरी डॉक्यूमेंट; दो लॉन्च मोड (EHR लॉन्च, जहाँ EHR वर्तमान रोगी के संदर्भ में ऐप खोलता है, और स्टैंडअलोन लॉन्च, जहाँ उपयोगकर्ता ऐप खोलता है और एक रोगी चुनता है); FHIR-जागरूक सिंटैक्स में स्कोप (patient/Observation.rs का मतलब है संदर्भ में रोगी के अवलोकन को पढ़ना और खोजना); टोकन के साथ लौटाया गया लॉन्च संदर्भ (कौन सा रोगी, कौन सा एनकाउंटर); और सिस्टम-से-सिस्टम एक्सेस के लिए हस्ताक्षरित JWT क्लाइंट प्रमाणीकरण के लिए बैकएंड सेवाएँ। SMART v2 (2021 से) ने PKCE को अनिवार्य कर दिया, दानेदार स्कोप और एसिमेट्रिक क्लाइंट प्रमाणीकरण जोड़ा, और यह वह संस्करण है जिसकी राष्ट्रीय कार्यक्रम आवश्यकता होती है।

चरण 1: डिस्कवरी

SMART ऐप लॉन्च की खोज ऐप द्वारा FHIR सर्वर के .well-known/smart-configuration दस्तावेज़ को फ़ेच करने से शुरू होती है, जिसमें प्राधिकरण और टोकन एंडपॉइंट, समर्थित क्षमताएं (EHR लॉन्च, स्टैंडअलोन लॉन्च, सार्वजनिक और गोपनीय क्लाइंट, OpenID Connect, रोगी और उपयोगकर्ता अनुमतियां), समर्थित स्कोप, 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 ऐप लॉन्च के दो लॉन्च मोड होते हैं। EHR लॉन्च में, डॉक्टर EHR के अंदर ऐप खोलता है, जो एक iss पैरामीटर (FHIR सर्वर) और वर्तमान रोगी और मुठभेड़ को एन्कोड करने वाला एक अपारदर्शी लॉन्च टोकन पास करता है। स्टैंडअलोन लॉन्च में, उपयोगकर्ता सीधे ऐप खोलता है और प्राधिकरण सर्वर उनसे रोगी चुनने या पुष्टि करने के लिए कहता है।

EHR लॉन्च। डॉक्टर EHR के अंदर ऐप पर क्लिक करता है; EHR ऐप के लॉन्च URL को दो पैरामीटर के साथ खोलता है: iss (FHIR सर्वर) और launch (एक अपारदर्शी टोकन जो वर्तमान रोगी और एनकाउंटर को एन्कोड करता है)। ऐप को अपने प्राधिकरण अनुरोध में launch स्कोप के साथ launch को इको करना होगा।

स्टैंडअलोन लॉन्च। उपयोगकर्ता सीधे ऐप खोलता है; ऐप FHIR सर्वर को जानता है (चुना हुआ या कॉन्फ़िगर किया हुआ) और launch/patient के साथ संदर्भ के लिए पूछता है; प्राधिकरण सर्वर उपयोगकर्ता से एक रोगी को चुनने या पुष्टि करने के लिए कहता है।

चरण 3: PKCE के साथ प्राधिकरण कोड

SMART प्राधिकरण चरण PKCE के साथ OAuth 2.0 प्राधिकरण कोड प्रवाह है: ऐप उपयोगकर्ता को उसके स्कोप, FHIR सर्वर के aud और कोड चुनौती के साथ प्राधिकरण एंडपॉइंट पर भेजता है; उपयोगकर्ता प्रमाणित करता है और अनुमोदित करता है; ऐप लौटे कोड और कोड वेरिफ़ायर को एक्सेस टोकन के लिए एक्सचेंज करता है जो लॉन्च संदर्भ के साथ आता है।

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) टोकन के साथ आता है। पब्लिक क्लाइंट (मोबाइल और ब्राउज़र ऐप) PKCE और कोई क्लाइंट सीक्रेट का उपयोग करते हैं; गोपनीय क्लाइंट सीक्रेट के साथ या, अधिमानतः, एसिमेट्रिक विधि के तहत हस्ताक्षरित JWT (private_key_jwt) के साथ प्रमाणित होते हैं।

स्कोप

SMART on FHIR v2 स्कोप संदर्भ/संसाधन.अनुमतियां सिंटैक्स का उपयोग करते हैं, जहां संदर्भ रोगी, उपयोगकर्ता या सिस्टम होता है और अनुमतियां c, r, u, d और s को रोगी/Observation.rs की तरह बनाने, पढ़ने, अपडेट करने, हटाने और खोजने के लिए जोड़ती हैं। ग्रैनुलर स्कोप एक फ़िल्टर जोड़ते हैं, openid और fhirUser उपयोगकर्ता की पहचान देते हैं, लॉन्च स्कोप संदर्भ का अनुरोध करते हैं, और offline_access एक रीफ़्रेश टोकन का अनुरोध करता है।

SMART v2 सिंटैक्स: <context>/<resource>.<permissions> जहाँ संदर्भ patient (संदर्भ में रोगी), user (जो कुछ भी उपयोगकर्ता देख सकता है) या system (बैकएंड) है, और अनुमतियाँ c create, r read, u update, d delete, s search में से कोई भी हैं, उसी क्रम में: patient/Observation.rs, user/Patient.rs, system/*.cruds। दानेदार स्कोप एक फ़िल्टर जोड़ते हैं: patient/Observation.rs?category=http://terminology.hl7.org/CodeSystem/observation-category|vital-signs। openid fhirUser एक आईडी टोकन और उपयोगकर्ता की FHIR पहचान देते हैं; launch, launch/patient, launch/encounter संदर्भ का अनुरोध करते हैं; offline_access उपयोगकर्ता के दूर होने पर उपयोग के लिए एक रिफ्रेश टोकन, online_access केवल सत्र के दौरान मान्य। v1 सिंटैक्स (patient/Observation.read) अभी भी कई सर्वरों द्वारा स्वीकार किया जाता है।

बैकएंड सेवाएँ

किसी ऐसे सिस्टम के लिए जो उपयोगकर्ता के बिना कार्य करता है (एक रात का निर्यात, एक एकीकरण इंजन), SMART बैकएंड सेवाएँ हस्ताक्षरित JWT अभिकथन (JWKS URL पर प्रकाशित क्लाइंट की सार्वजनिक कुंजी) और system/ स्कोप के साथ client_credentials का उपयोग करती हैं। कोई उपयोगकर्ता नहीं, कोई लॉन्च संदर्भ नहीं, सख्त पंजीकरण।

इसे सुरक्षित रूप से चलाना

SMART ऐप लॉन्च को सुरक्षित रूप से चलाने का मतलब है सटीक रीडायरेक्ट URIs को पंजीकृत करना, कभी भी इम्प्लिसिट फ़्लो का उपयोग न करना, रीफ़्रेश टोकन को सुरक्षित रूप से स्टोर करना और रोटेट करना, ID टोकन के state और aud को मान्य करना, हर API कॉल पर टोकन को सत्यापित करना, डेटा लेयर पर स्कोप और रोगी संदर्भ दोनों को लागू करना ताकि एक रोगी के लिए टोकन कभी भी दूसरे को न पढ़े, और हर एक्सेस को लॉग करना।

सटीक रीडायरेक्ट URI पंजीकृत करें; कभी भी इम्प्लिसिट फ्लो का उपयोग न करें; रिफ्रेश टोकन को सुरक्षित रूप से स्टोर करें और उन्हें रोटेट करें; state को मान्य करें; आईडी टोकन के aud की जाँच करें; हर API कॉल पर टोकन को सत्यापित करें (इंट्रोस्पेक्शन या JWT सत्यापन) और डेटा लेयर पर स्कोप और रोगी संदर्भ लागू करें, क्योंकि Patient/123 के लिए एक टोकन को कभी भी Patient/124 नहीं पढ़ना चाहिए; हर एक्सेस को लॉग करें (सुरक्षा और पहचान: मानचित्र)। SMART रोगी एक्सेस ब्रांड को भी परिभाषित करता है, जो ऐप्स के लिए उपयोगकर्ताओं को यह दिखाने का एक तरीका है कि वे किन संगठनों से जुड़ सकते हैं, और रोगी-आरंभित साझाकरण के लिए SMART हेल्थ लिंक के साथ इंटरऑपरेट करता है।

कहाँ इसकी आवश्यकता है

यूएस रोगी-पहुँच नियमों के लिए प्रमाणित EHR को SMART App Launch और Backend Services का समर्थन करने की आवश्यकता होती है; यूरोप में राष्ट्रीय कार्यक्रम ऐप एक्सेस के लिए इसे अपनाते हैं (नीदरलैंड का MedMij OAuth 2.0 का उपयोग समतुल्य परंपराओं के साथ करता है); IPS और कई कार्यान्वयन गाइड इसे मानते हैं। TEFCA और राष्ट्रीय इलेक्ट्रॉनिक स्वास्थ्य रिकॉर्ड देखें।

Anpheros में

Anpheros Platform ऐप्स के लिए PKCE और बैकएंड के लिए हस्ताक्षरित-JWT क्लाइंट प्रमाणीकरण के साथ OAuth 2.0 का उपयोग करता है, जिसमें व्यक्ति की सहमति से प्राप्त स्कोप और हर अनुरोध पर लागू रोगी संदर्भ होता है। डेवलपर साइट इस पर निर्माण के लिए प्रमाणीकरण और SMART on FHIR बैकएंड पैटर्न का दस्तावेजीकरण करती है।

स्रोत

अक्सर पूछे जाने वाले प्रश्न

क्या SMART on FHIR OAuth 2.0 के समान है?

यह FHIR-विशिष्ट परिवर्धन के साथ OAuth 2.0 और OpenID Connect है: डिस्कवरी, लॉन्च संदर्भ, स्कोप सिंटैक्स और बैकएंड सेवाएँ। कोई भी OAuth लाइब्रेरी काम करती है; SMART परंपराएँ ही हैं जो किसी ऐप को FHIR सर्वर पर पोर्टेबल बनाती हैं।

क्या मुझे सर्वर-साइड ऐप के लिए PKCE की आवश्यकता है?

SMART v2 में, हाँ, प्राधिकरण कोड फ्लो का उपयोग करने वाले सभी क्लाइंट के लिए। गोपनीय क्लाइंट ऊपर से क्लाइंट प्रमाणीकरण (एक सीक्रेट या हस्ताक्षरित JWT) जोड़ते हैं।

patient/ और user/ स्कोप के बीच क्या अंतर है?

patient/ लॉन्च संदर्भ में एकल रोगी तक पहुँच को सीमित करता है; user/ वह सब कुछ प्रदान करता है जिसे प्रमाणित उपयोगकर्ता देख सकता है, रोगियों में। रोगी-सामना करने वाले ऐप patient/ का उपयोग करते हैं; डॉक्टर ऐप अक्सर संदर्भ के साथ user/ का उपयोग करते हैं।

क्या SMART ऐप रिकॉर्ड में लिख सकता है?

यदि उसके स्कोप में निर्माण या अद्यतन अनुमतियाँ (c, u) दी गई हैं और सर्वर इसकी अनुमति देता है। कई परिनियोजन रोगी ऐप्स को केवल पढ़ने और खोजने की अनुमति देते हैं, और QuestionnaireResponse जैसे विशिष्ट संसाधनों के माध्यम से राइट्स को रूट करते हैं।

Anpheros Platform

सैंडबॉक्स में मुफ़्त आज़माएँ

5 मिनट में आपकी पहली FHIR कॉल. एक HL7 FHIR R4 API जिसमें मरीज़ की सहमति शामिल है: सैंडबॉक्स में आज़माएं, फिर अपना ऐप या क्लिनिक सिस्टम कनेक्ट करें।

मुफ़्त सैंडबॉक्स बनाएँ सैंपल ऐप चलाएँ →स्टार्टर कोड (Python) →Postman कलेक्शन →डेवलपर गाइड पढ़ें →

मुफ़्त · 30 सिंथेटिक मरीज़ · कोई कार्ड नहीं

यह गाइड केवल जानकारी के लिए है और चिकित्सा सलाह का विकल्प नहीं है। अपने स्वास्थ्य संबंधी निर्णयों के लिए, अपने डॉक्टर से बात करें। आपात स्थिति में अपने स्थानीय आपातकालीन नंबर पर कॉल करें (यूरोप में 112)।

द्वारा लिखित

Anpheros टीम

Anpheros एक मेडिकल रिकॉर्ड बनाता है जिसे मरीज़ नियंत्रित कर सकता है और किसी भी क्लिनिक के साथ साझा कर सकता है, यह EU में स्थित HL7 FHIR R4 प्लेटफ़ॉर्म पर आधारित है। ये गाइड आपको अपने स्वास्थ्य को समझने और व्यवस्थित करने में मदद करते हैं; ये आपके डॉक्टर का विकल्प नहीं हैं।

Anpheros के बारे में →