संक्षिप्त उत्तर: एक स्वास्थ्य ऐप में सुरक्षा चार सवालों के जवाब देती है, क्रम से। यह कौन है? पहचान: OpenID Connect के माध्यम से एक सत्यापित उपयोगकर्ता (रोगी, चिकित्सक, प्रणाली) और, चिकित्सकों के लिए, राष्ट्रीय पेशेवर पहचान; सत्यापन स्तर पासवर्ड की ताकत से अधिक मायने रखता है। वे क्या कर सकते हैं? प्राधिकरण: OAuth 2.0 (2.1 में स्थानांतरित हो रहा है) टोकन स्कोप के साथ SMART on FHIR सिंटैक्स में, रोगी की सहमति से एक उद्देश्य और अवधि के लिए प्राप्त, डेटा परत पर लागू। उन्होंने क्या किया? जवाबदेही: एक एक्सेस लॉग जिसे रोगी पढ़ सकता है और संगठन के लिए एक FHIR AuditEvent ट्रेल। क्या डेटा आराम पर, ट्रांज़िट में और बैकअप में सुरक्षित है? सुरक्षा: एन्क्रिप्शन, कुंजी प्रबंधन, अलगाव, परीक्षण किए गए पुनर्स्थापना। उनके चारों ओर: ISO 27001 और 27799, NIS2 और HIPAA की सुरक्षा नियम का आधार, और स्वास्थ्य डेटा के विशिष्ट खतरे (आंतरिक ब्राउज़िंग, गलत फाइलिंग, रैंसमवेयर)।
नक्शा
स्वास्थ्य ऐप में सुरक्षा और पहचान सात परतों से बनती हैं: OpenID Connect और राष्ट्रीय या पेशेवर आईडी के माध्यम से पहचान, OAuth 2.0 और SMART on FHIR स्कोप के माध्यम से प्राधिकरण, हर अनुमति का स्रोत के रूप में सहमति, एक्सेस लॉग और FHIR AuditEvent के माध्यम से जवाबदेही, एन्क्रिप्शन और बैकअप के माध्यम से सुरक्षा, ISO 27001, ISO 27799, NIS2 और HIPAA का आधार, और रोगी द्वारा शुरू की गई साझाकरण।
| परत | मानक या अभ्यास | आपको क्या मिलता है | पृष्ठ |
|---|---|---|---|
| पहचान | OpenID Connect; राष्ट्रीय आईडी (eIDAS, NHS लॉगिन, GesundheitsID); पेशेवर पहचान (eHBA, CPS, UZI) | आश्वासन स्तर के साथ एक सत्यापित विषय | SMART ऐप लॉन्च समझाया गया |
| प्राधिकरण | OAuth 2.0 और 2.1 (PKCE अनिवार्य, कोई निहित या पासवर्ड अनुदान नहीं); SMART on FHIR स्कोप (patient/Observation.rs); असममित क्लाइंट प्रमाणीकरण के साथ बैकएंड सेवाएं | एक उपयोगकर्ता, एक रोगी संदर्भ और एक स्कोप से बंधे टोकन | SMART ऐप लॉन्च समझाया गया, SMART on FHIR बैकएंड |
| सहमति | FHIR Consent; उद्देश्य- और समय-बाध्य अनुदान; निरसन; औचित्य और अलर्ट के साथ ब्रेक-द-ग्लास | हर प्राधिकरण का स्रोत रोगी | रोगी सहमति मंच, क्लिनिक एक्सेस अनुरोध |
| जवाबदेही | रोगी द्वारा देखे जाने वाले प्रति-रिकॉर्ड एक्सेस लॉग; FHIR AuditEvent; छेड़छाड़-सबूत भंडारण; प्रतिधारण | किसने क्या, कब, क्यों देखा | मेरे मेडिकल रिकॉर्ड को किसने देखा? |
| सुरक्षा | TLS 1.2+, प्रबंधित कुंजियों के साथ आराम पर एन्क्रिप्शन, पहचानकर्ताओं के लिए फ़ील्ड-स्तरीय एन्क्रिप्शन, अलग वातावरण, परीक्षण किए गए पुनर्स्थापना के साथ बैकअप | गोपनीयता और उपलब्धता | ISO 27001 बनाम ISO 27799 |
| आधार रेखा | ISO 27001 ISMS, 27799 स्वास्थ्य नियंत्रण, NIS2 उपाय, HIPAA सुरक्षा नियम, राष्ट्रीय योजनाएं (HDS, DSPT, C5) | अस्पताल, ऑडिटर और नियामक क्या उम्मीद करते हैं | अस्पतालों और विक्रेताओं के लिए NIS2, HIPAA बनाम GDPR |
| साझा करना | SMART Health Links और Cards; सत्यापन योग्य क्रेडेंशियल | लिंक या क्यूआर के साथ रोगी-आरंभित साझाकरण, निरस्त करने योग्य | SMART Health Links समझाया गया |
पहचान: पासवर्ड से अधिक आश्वासन
स्वास्थ्य ऐप में पहचान पासवर्ड की ताकत के बजाय आश्वासन पर निर्भर करती है: पहचान आश्वासन स्तर जैसे NIST IAL, eIDAS सबस्टैंशियल और हाई, या NHS लॉगिन P9 बताते हैं कि नामांकन के समय किसी व्यक्ति को कितनी मजबूती से सत्यापित किया गया था, जबकि मल्टी-फैक्टर ऑथेंटिकेशन और पासकी प्रत्येक लॉगिन का वर्णन करते हैं। चिकित्सकों की पहचान पेशेवर पहचान के माध्यम से की जाती है जिसे उनके जाने पर रद्द कर दिया जाता है।
एक रोगी ऐप जो एक पूर्ण रिकॉर्ड दिखाता है, उसे यह जानना होगा कि वह उस रोगी से बात कर रहा है। पहचान आश्वासन स्तर (NIST का IAL, eIDAS पर्याप्त और उच्च, NHS लॉगिन P9) बताते हैं कि नामांकन के समय पहचान कितनी मजबूती से सत्यापित की गई थी; प्रमाणीकरण शक्ति (बहु-कारक, पासकी) प्रत्येक लॉगिन का वर्णन करती है। अस्पताल और राष्ट्रीय प्रणालियाँ तेजी से स्व-घोषित साइन-अप के बजाय मान्यता प्राप्त योजनाओं से सत्यापित पहचान की मांग कर रही हैं, और यूरोपीय संघ डिजिटल पहचान वॉलेट एक स्वीकृत माध्यम बन जाएगा। चिकित्सकों के लिए, पेशेवर पहचान (और किसी के चले जाने पर उसका निरसन) वह रिकॉर्ड प्रणाली है जो यह निर्धारित करती है कि कौन चिकित्सक के रूप में कार्य कर सकता है।
प्राधिकरण: सहमति स्कोप बन जाती है
रोगी-नियंत्रित रिकॉर्ड में प्राधिकरण रोगी की सहमति का अनुवाद करता है, जैसे कि किसी क्लिनिक को 90 दिनों के लिए लैब परिणाम और स्थितियों को पढ़ने की अनुमति देना, OAuth स्कोप और टोकन पर रोगी संदर्भ में, SMART on FHIR सिंटैक्स जैसे patient/Observation.rs में, हर अनुरोध पर डेटा परत पर लागू किया जाता है और जब रोगी वापस ले लेता है तो रद्द कर दिया जाता है। ब्रेक-द-ग्लास एक अलग, ऑडिटेड पथ है।
रोगी-नियंत्रित रिकॉर्ड में, रोगी की सहमति नीति है: यह क्लिनिक 90 दिनों के लिए मेरे लैब परिणाम और स्थितियाँ पढ़ सकता है। सिस्टम इसे OAuth स्कोप और संदर्भ (कौन सा रोगी, कौन से संसाधन, कौन से ऑपरेशन) में अनुवादित करता है टोकन पर जो क्लिनिक की प्रणाली प्राप्त करती है, डेटा परत पर हर अनुरोध पर उन्हें लागू करती है, और जब रोगी वापस ले लेता है तो उन्हें निरस्त कर देती है। SMART on FHIR का स्कोप सिंटैक्स (patient/Observation.rs, patient/Condition.rs) इसके लिए सामान्य भाषा है; बारीक नियंत्रण के लिए SMART v2 में बारीक स्कोप (श्रेणी या कोड द्वारा) मौजूद हैं। ब्रेक-द-ग्लास (सहमति के बिना आपातकालीन पहुंच) एक अलग, ऑडिटेड पथ है जिसमें अनिवार्य औचित्य और रोगी को अलर्ट शामिल है, कभी भी डिफ़ॉल्ट नहीं। रोगी सहमति मंच देखें।
जवाबदेही: वह लॉग जिसे रोगी पढ़ता है
स्वास्थ्य ऐप में जवाबदेही का मतलब है कि रिकॉर्ड तक हर पहुंच, किसके द्वारा, कब, क्या और किस सहमति के तहत, एक अपेंड-ओनली लॉग में लिखी जाती है जिसे रोगी अपने ऐप में पढ़ सकता है और FHIR AuditEvent में एक संगठनात्मक ऑडिट ट्रेल में। ISO 27799 इसे अनिवार्य मानता है, और एक दृश्यमान लॉग आंतरिक ब्राउज़िंग के लिए सबसे मजबूत निवारक है।
रिकॉर्ड तक हर पहुंच, किसके द्वारा, कब, क्या, किस सहमति के तहत, एक अपेंड-ओनली लॉग में लिखा गया है जिसे रोगी अपने ऐप में पढ़ सकता है, और सुरक्षा टीमों के लिए एक संगठनात्मक ऑडिट ट्रेल (FHIR AuditEvent) में। ISO 27799 इसे स्वास्थ्य जानकारी के लिए अनिवार्य मानता है; GDPR का पारदर्शिता सिद्धांत और EHDS के रोगी अधिकार एक ही दिशा में इशारा करते हैं; आंतरिक ब्राउज़िंग के लिए सबसे बड़ा वास्तविक दुनिया निवारक एक दृश्य लॉग है। मेरे मेडिकल रिकॉर्ड को किसने देखा? देखें।
सुरक्षा: इंजीनियरिंग आधार रेखा
स्वास्थ्य डेटा की सुरक्षा के लिए इंजीनियरिंग आधार रेखा हर जगह TLS है, प्रबंधित, घुमाई गई कुंजियों के साथ रेस्ट पर एन्क्रिप्शन, प्रत्यक्ष पहचानकर्ताओं के लिए अलग एन्क्रिप्शन या टोकनाइजेशन, उत्पादन के बाहर सिंथेटिक डेटा के साथ अलग-अलग वातावरण, प्रशासकों के लिए मल्टी-फैक्टर ऑथेंटिकेशन के साथ न्यूनतम-विशेषाधिकार एक्सेस, सीक्रेट्स और भेद्यता प्रबंधन, रैंसमवेयर के खिलाफ पुनर्स्थापना द्वारा परीक्षण किए गए एन्क्रिप्टेड बैकअप, और GDPR और NIS2 घड़ियों के भीतर घटना प्रतिक्रिया है।
हर जगह TLS, आधुनिक सिफर और ऐप्स में उपयुक्त होने पर प्रमाणपत्र पिनिंग के साथ; प्रबंधित कुंजी सेवा में कुंजियों के साथ आराम पर एन्क्रिप्शन और रोटेशन; प्रत्यक्ष पहचानकर्ताओं के लिए अलग एन्क्रिप्शन या टोकनाइजेशन; उत्पादन से विकास का अलगाव, उत्पादन के बाहर सिंथेटिक डेटा के साथ; कर्मचारियों के लिए न्यूनतम-विशेषाधिकार पहुंच, कोई साझा खाते नहीं, सभी प्रशासनिक पहुंच के लिए बहु-कारक; रहस्य प्रबंधन; प्रकटीकरण के साथ निर्भरता और भेद्यता प्रबंधन; एन्क्रिप्टेड बैकअप, पुनर्स्थापना द्वारा परीक्षण किए गए, और रैंसमवेयर से सुरक्षित जो बार-बार अस्पतालों और प्रयोगशालाओं को प्रभावित किया है (2017 में WannaCry, 2020 में डसेलडोर्फ अस्पताल, 2024 में Change Healthcare और Synnovis)। एक रनबुक में 72-घंटे GDPR और 24-घंटे NIS2 घड़ियों के साथ घटना प्रतिक्रिया।
स्वास्थ्य डेटा के लिए विशिष्ट खतरे
स्वास्थ्य डेटा के लिए विशिष्ट खतरे परिचितों के रिकॉर्ड का आंतरिक ब्राउज़िंग, रोगियों के बीच गलत फाइलिंग, बहुत लंबे समय के लिए दी गई अत्यधिक व्यापक साझाकरण, स्वास्थ्य डेटा को संभालने वाले ऐप्स के अंदर विज्ञापन SDKs, AI सुविधाओं में दस्तावेज़-जनित इंजेक्शन, और दशकों तक लंबा प्रतिधारण है जिसके दौरान कुंजियों, प्रारूपों और एक्सेस नियमों को कर्मचारियों और विक्रेताओं से अधिक समय तक जीवित रहना चाहिए।
- परिचितों या सार्वजनिक हस्तियों के रिकॉर्ड का आंतरिक ब्राउज़िंग: संबंध-आधारित पहुंच और दृश्य लॉग।
- रोगियों के बीच गलत फाइलिंग: पहचान सुलह और उत्पत्ति, न केवल पहुंच नियंत्रण।
- अत्यधिक व्यापक साझाकरण: एक क्लिनिक जिसे एक वर्ष के लिए "सब कुछ" प्रदान किया गया था; उचित डिफ़ॉल्ट के साथ स्कोप और अवधि।
- विज्ञापन SDK वाले ऐप्स: स्वास्थ्य डेटा को संभालने वाली किसी भी चीज़ में कोई तृतीय-पक्ष ट्रैकर नहीं।
- AI सुविधाओं में दस्तावेज़-जनित इंजेक्शन: सामग्री डेटा है, निर्देश नहीं (मेडिकल रिकॉर्ड पर RAG)।
- लंबा प्रतिधारण: रिकॉर्ड दशकों तक चलते हैं; कुंजियों, प्रारूपों और पहुंच नियमों को कर्मचारियों और विक्रेताओं से जीवित रहना चाहिए।
Anpheros में
Anpheros स्वयं पर सुरक्षा मानचित्र लागू करता है जिसमें ऐप्स के लिए PKCE के साथ OAuth 2.0 और बैकएंड के लिए एसिमेट्रिक क्लाइंट ऑथेंटिकेशन, हर क्लिनिक की पहुंच के स्रोत के रूप में प्रति उद्देश्य और अवधि के अनुसार सहमति, व्यक्ति के ऐप में प्रति-रिकॉर्ड एक्सेस लॉग, रेस्ट और ट्रांज़िट में एन्क्रिप्शन, EU होस्टिंग, कोई विज्ञापन SDKs नहीं, और ISO 27001 और 27799 के अनुसार एक ISMS शामिल है।
Anpheros इस नक्शे को स्वयं पर लागू करता है: ऐप्स के लिए PKCE के साथ OAuth 2.0 और बैकएंड के लिए असममित क्लाइंट प्रमाणीकरण; हर क्लिनिक की पहुंच के स्रोत के रूप में उद्देश्य और अवधि के अनुसार सहमति, निरसन के साथ और कोई मूक ब्रेक-द-ग्लास नहीं; व्यक्ति के ऐप में प्रति-रिकॉर्ड एक्सेस लॉग; आराम पर और ट्रांज़िट में एन्क्रिप्शन, यूरोपीय संघ होस्टिंग, कोई विज्ञापन SDK नहीं; 27799 स्वास्थ्य नियंत्रण के साथ ISO 27001 के अनुसार एक ISMS। डेवलपर साइट प्रमाणीकरण, सहमति और सुरक्षा का दस्तावेजीकरण करती है।
संबंधित पृष्ठ
- SMART ऐप लॉन्च समझाया गया
- रोगी सहमति मंच
- मेरे मेडिकल रिकॉर्ड को किसने देखा?
- SMART Health Links समझाया गया
- ISO 27001 बनाम ISO 27799
- अस्पतालों और स्वास्थ्य-तकनीक विक्रेताओं के लिए NIS2
- प्लेटफ़ॉर्म सुरक्षा (डेवलपर साइट)
- प्रमाणीकरण (डेवलपर साइट)
स्रोत
- HL7 SMART ऐप लॉन्च
- IETF: OAuth 2.1 (ड्राफ्ट)
- OpenID Connect Core 1.0
- HL7 FHIR R4: AuditEvent
- HL7 FHIR R4: Consent
- NIST SP 800-63-4: डिजिटल पहचान दिशानिर्देश
- ISO 27799:2016
- ENISA: अस्पतालों में साइबर सुरक्षा के लिए खरीद दिशानिर्देश
अक्सर पूछे जाने वाले प्रश्न
क्या OAuth 2.1 2.0 से अलग है?
OAuth 2.1, 2.0 को उसकी सुरक्षा सर्वोत्तम प्रथाओं के साथ समेकित करता है: सभी क्लाइंट के लिए PKCE आवश्यक है, निहित और पासवर्ड अनुदान हटा दिए गए हैं, रीडायरेक्ट यूआरआई बिल्कुल मेल खाने चाहिए, और सार्वजनिक क्लाइंट के लिए रीफ़्रेश टोकन बाउंड या रोटेट किए जाने चाहिए। SMART on FHIR v2 पहले से ही इनमें से अधिकांश की आवश्यकता है।
ब्रेक-द-ग्लास क्या है?
रोगी की पूर्व सहमति के बिना रिकॉर्ड तक आपातकालीन पहुंच, एक चिकित्सक द्वारा जो औचित्य बताता है। यह दुर्लभ, लॉग, समीक्षा और रोगी को रिपोर्ट किया जाना चाहिए; यह कभी भी डिफ़ॉल्ट एक्सेस पथ नहीं है।
रोगियों को एक्सेस लॉग क्यों देखना चाहिए?
क्योंकि यह अनुचित पहुंच के लिए सबसे मजबूत निवारक है और नियंत्रण की सबसे स्पष्ट अभिव्यक्ति है: व्यक्ति देखता है कि किस क्लिनिक ने क्या और कब पढ़ा, और निरस्त कर सकता है। ISO 27799 और EHDS एक ही दिशा में इशारा करते हैं।
क्या मुझे एक अलग ऑडिट सिस्टम की आवश्यकता है?
आपको एक अपेंड-ओनली ऑडिट ट्रेल (FHIR AuditEvent या समकक्ष) की आवश्यकता है जिसे एप्लिकेशन बदल नहीं सकता है, नीति के अनुसार बनाए रखा गया है, और उससे प्राप्त रोगी-सामना वाला दृश्य। चाहे वह एक अलग प्रणाली हो या प्लेटफ़ॉर्म के अंदर एक संरक्षित स्टोर, यह एक कार्यान्वयन विकल्प है।
सैंडबॉक्स में मुफ़्त आज़माएँ
5 मिनट में आपकी पहली FHIR कॉल. एक HL7 FHIR R4 API जिसमें मरीज़ की सहमति शामिल है: सैंडबॉक्स में आज़माएं, फिर अपना ऐप या क्लिनिक सिस्टम कनेक्ट करें।
मुफ़्त · 30 सिंथेटिक मरीज़ · कोई कार्ड नहीं
Anpheros एक मेडिकल रिकॉर्ड बनाता है जिसे मरीज़ नियंत्रित कर सकता है और किसी भी क्लिनिक के साथ साझा कर सकता है, यह EU में स्थित HL7 FHIR R4 प्लेटफ़ॉर्म पर आधारित है। ये गाइड आपको अपने स्वास्थ्य को समझने और व्यवस्थित करने में मदद करते हैं; ये आपके डॉक्टर का विकल्प नहीं हैं।
Anpheros के बारे में →