# सुरक्षा, गोपनीयता और डेटा निवास

> रोगी डेटा को कैसे सुरक्षित रखा जाता है: यूरोपीय संघ डेटा निवास, परियोजना अलगाव, जोड़ीदार आईडी, क्रेडेंशियल, सहमति, उत्पत्ति, रोगी के लिए एक ऑडिट योग्य ऑडिट, और निजी बीटा की सीमाएँ।

Source: https://developers.anpheros.com/hi/guides/security

चिकित्सा डेटा किसी एप्लिकेशन द्वारा रखी जा सकने वाली सबसे संवेदनशील डेटा है। यह पृष्ठ सूचीबद्ध करता है कि Anpheros Platform आज इसे कैसे सुरक्षित रखता है - केवल वही जो लागू किया गया है - और निजी बीटा के दौरान अभी भी क्या सीमित है।

## डेटा निवास

- सभी प्लेटफ़ॉर्म डेटा यूरोपीय संघ में संग्रहीत और संसाधित किया जाता है: Google Cloud `europe-west4` (नीदरलैंड्स) में सेवा और इसके डेटाबेस, `europe-west3` (फ्रैंकफर्ट) में वेबहुक डिलीवरी कतार, और BigQuery EU स्थान में एक्सेस लॉग का केवल-जोड़ने वाला निर्यात।
- **यूएस डेटा क्षेत्र:** HIPAA व्यावसायिक सहयोगी समझौते के तहत उत्पादन ग्राहकों के लिए अनुरोध पर उपलब्ध (नीचे देखें); यूएस रोगी डेटा तब यूएस क्षेत्र को कभी नहीं छोड़ता है।
- दस्तावेज़ ग्राहक-प्रबंधित एन्क्रिप्शन कुंजी (CMEK) के साथ एन्क्रिप्टेड एक ईयू स्टोरेज बकेट में संग्रहीत किए जाते हैं। अंतिम रूप देने के बाद मूल अपरिवर्तनीय होते हैं; उनके SHA-256 चेकसम और आकार दर्ज किए जाते हैं।

## अनुप्रयोगों के बीच अलगाव

- प्रत्येक API कुंजी एक **प्रोजेक्ट** से संबंधित होती है। एक प्रोजेक्ट केवल उन रोगियों को देखता है जिन्हें उसने बनाया है — सैंडबॉक्स में, जिसमें सिंथेटिक रोगियों की अपनी प्रतिलिपि भी शामिल है, जिसे कोई अन्य प्रोजेक्ट नहीं देख सकता है।
- **युग्मित पहचानकर्ता (Pairwise identifiers):** प्रत्येक प्रोजेक्ट को एक ही व्यक्ति के लिए अपना आईडी प्राप्त होता है; आंतरिक आईडी कभी भी प्लेटफ़ॉर्म से बाहर नहीं जाते हैं, इसलिए आईडी को अनुप्रयोगों के बीच सहसंबंधित नहीं किया जा सकता है।
- एक रिकॉर्ड जिसे आप एक्सेस नहीं कर सकते, वह `404` का उत्तर देता है, कभी भी `403` का नहीं, इसलिए किसी रोगी के अस्तित्व की जांच नहीं की जा सकती है।
- **सैंडबॉक्स और प्रोडक्शन अलग-अलग डेटाबेस हैं।** एक सैंडबॉक्स कुंजी (`sk_test_`) भौतिक रूप से वास्तविक रोगियों तक नहीं पहुंच सकती है।
- रोगी की सहमति से एक संगठन पूरे रिकॉर्ड को पढ़ता है, जिसमें अन्य संगठनों ने क्या लिखा है, वह भी शामिल है, लेकिन वह केवल वही बदल या हटा सकता है जो उसने स्वयं लिखा है।

## क्रेडेंशियल्स

- API कीज़ एक बार दिखाई जाती हैं और केवल SHA-256 हैश के रूप में संग्रहीत की जाती हैं। कीज़ में `read` / `write` स्कोप होते हैं और वे कभी भी अपने एनवायरनमेंट को पार नहीं करती हैं।
- OAuth 2.1 अनिवार्य PKCE (S256) के साथ; `redirect_uri` को ठीक से पंजीकृत किया जाना चाहिए। एक्सेस टोकन 30 मिनट तक चलते हैं, रिफ्रेश टोकन 30 दिन तक चलते हैं और हर उपयोग पर रोटेट होते हैं।
- **रिफ्रेश-टोकन के पुनः उपयोग का पता लगाना:** पहले से उपयोग किए गए रिफ्रेश टोकन को प्रस्तुत करने से पूरे टोकन चेन को रद्द कर दिया जाता है।
- टोकन रिस्पॉन्स में `Cache-Control: no-store` होता है। OpenID Connect `id_token` RS256 के साथ हस्ताक्षरित होते हैं; पब्लिक कीज़ `/oauth/jwks` पर प्रकाशित की जाती हैं।

## सहमति, उत्पत्ति और ऑडिट

- एक मरीज़ किसी होस्टेड सहमति पृष्ठ पर किसी एप्लिकेशन को रिकॉर्ड और अवधि (30, 90, 180 या 365 दिन) चुनकर पहुँच प्रदान करता है। स्कोप प्रति संसाधन प्रकार और क्रिया के लिए होते हैं, वैकल्पिक रूप से श्रेणी के अनुसार फ़िल्टर किए जाते हैं। हर अनुमति को एक FHIR `Consent` संसाधन के रूप में दर्शाया जाता है।
- निरस्तीकरण अगले अनुरोध पर प्रभावी होता है; एप्लिकेशन वापस ताज़ा नहीं कर सकता।
- **हर लेखन** एक `Provenance` संसाधन उत्पन्न करता है: किसने लिखा (मरीज़, चिकित्सक, उपकरण, आयात या AI), किस संगठन के लिए, किस स्रोत प्रणाली से।
- **हर पठन लॉग किया जाता है और मरीज़ को दिखाई देता है**, जिसमें किसी प्रोजेक्ट की अपनी API कुंजी के साथ किए गए पठन भी शामिल हैं, और AI मॉडल के लिए निर्मित संदर्भ भी शामिल हैं।

## परिवहन और वेब सुरक्षा

- केवल HTTPS, HTTP Strict Transport Security के साथ। API प्रतिक्रियाएँ एक प्रतिबंधात्मक Content-Security-Policy, `X-Content-Type-Options: nosniff`, `X-Frame-Options: DENY` और एक सख्त रेफ़रर नीति ले जाती हैं।
- वेबहुक डिलीवरी को टाइमस्टैम्प और बॉडी पर HMAC-SHA256 के साथ हस्ताक्षरित किया जाता है; प्राप्तकर्ताओं को 5 मिनट से पुराने हस्ताक्षर अस्वीकार करने चाहिए। ईवेंट में आईडी और संस्करण होते हैं, कभी भी क्लिनिकल सामग्री नहीं।
- दर सीमाएँ: प्रति क्रेडेंशियल और प्रति IP प्रति मिनट 600 अनुरोध; 2 MiB तक JSON बॉडी; 25 MiB तक दस्तावेज़।

## सर्च इंजन और AI क्रॉलर

सार्वजनिक पृष्ठ (anpheros.com, प्लेटफ़ॉर्म प्रस्तुति और यह दस्तावेज़ीकरण) सर्च इंजन और AI क्रॉलर के लिए खुले हैं। API, डैशबोर्ड, OAuth और सहमति पृष्ठ और रोगी ऐप (`app.anpheros.com`) को `noindex` और `robots.txt` नियमों के साथ बाहर रखा गया है; उनमें से कोई भी प्रमाणीकरण के बिना रोगी डेटा वापस नहीं करता है।

## HIPAA (यूएस क्लिनिक)

संयुक्त राज्य अमेरिका में एक क्लिनिक के लिए, Anpheros एक **बिजनेस एसोसिएट** है। HIPAA सुरक्षा नियम के अनुसार क्या लागू है, इसका विवरण यहाँ दिया गया है:

| सुरक्षा उपाय | Anpheros इसे कैसे करता है |
|---|---|
| नियत जिम्मेदारी, जोखिम विश्लेषण, लिखित नीतियां (§164.308) | एक नामित सुरक्षा अधिकारी; एक वार्षिक जोखिम विश्लेषण; दस लिखित नीतियां (पहुंच, एन्क्रिप्शन, लॉगिंग, घटना प्रतिक्रिया, उल्लंघन अधिसूचना, प्रतिधारण और बैकअप, प्रशिक्षण, उपकरण, आपातकालीन पहुंच, विक्रेता), छह साल के लिए रखी गई हैं |
| अद्वितीय उपयोगकर्ता पहचान, पहुंच नियंत्रण (§164.312(a)) | हर कुंजी, टोकन और व्यक्ति की अपनी पहचान होती है; प्रोजेक्ट केवल अपने मरीज़ों को देखते हैं; हर रीड पर सहमति स्कोप लागू होते हैं; उत्पादन प्रोजेक्ट वाले संगठनों के लिए MFA या SSO आवश्यक है; डैशबोर्ड पर स्वचालित लॉगऑफ़ |
| ऑडिट नियंत्रण (§164.312(b)) | हर रीड और राइट लॉग किया जाता है, हैश-चेन किया जाता है, केवल-जोड़ने के रूप में निर्यात किया जाता है; मरीज़ के लिए दृश्यमान |
| अखंडता (§164.312(c)) | संस्करणित संसाधन, हर राइट पर प्रोवेनेंस, SHA-256 के साथ अपरिवर्तनीय दस्तावेज़ |
| ट्रांसमिशन सुरक्षा (§164.312(e)) | TLS 1.2+, HSTS, हस्ताक्षरित वेबहुक, केवल-HTTPS डिलीवरी |
| एन्क्रिप्शन एट रेस्ट | डेटाबेस और बैकअप एन्क्रिप्टेड; ग्राहक-प्रबंधित कुंजी के तहत दस्तावेज़ |
| आकस्मिक योजना (§164.308(a)(7)) | दैनिक बैकअप, पॉइंट-इन-टाइम रिकवरी, हर 90 दिनों में पुनर्स्थापना ड्रिल रिकॉर्ड किए गए समय के साथ |
| उल्लंघन अधिसूचना (§164.410) | कवर्ड एंटिटी को हमारे BAA द्वारा 5 व्यावसायिक दिनों के भीतर सूचित किया जाता है (कानून द्वारा 60 दिन) |
| बिजनेस एसोसिएट चेन (§164.308(b)) | Google Cloud अपने BAA के तहत; उप-प्रोसेसर सूची BAA अनुलग्नक में है |

उत्पादन ग्राहकों के लिए **बिजनेस एसोसिएट एग्रीमेंट** और **यूएस डेटा रीजन** अनुरोध पर उपलब्ध हैं (platform@anpheros.com पर लिखें); BAA पर हस्ताक्षर होने के बाद यूएस मरीज़ डेटा के लिए उत्पादन शुरू होता है। सैंडबॉक्स में केवल सिंथेटिक मरीज़ होते हैं, इसलिए यूएस में डेवलपर आज BAA के बिना निर्माण कर सकते हैं। Anpheros SOC 2 या HITRUST के विरुद्ध प्रमाणित नहीं है; जब कोई अस्पताल ग्राहक इसकी आवश्यकता करेगा तो SOC 2 टाइप II ऑडिट की योजना है।

## वर्तमान सीमाएँ (निजी बीटा)

- सिंगल-ज़ोन होस्टिंग बिना स्वचालित फेलओवर के; अभी तक कोई संविदात्मक SLA नहीं है।
- उत्पादन कुंजियाँ हस्ताक्षरित डेटा प्रोसेसिंग समझौते के साथ सत्यापित संगठनों को जारी की जाती हैं; बीटा भागीदार सिंथेटिक डेटा से शुरुआत करते हैं।
- SMART EHR लॉन्च और OpenID `nonce` पैरामीटर अभी समर्थित नहीं हैं।

## संबंधित

- [डेवलपर्स के लिए GDPR और स्वास्थ्य डेटा](https://developers.anpheros.com/hi/guides/gdpr-health-data-developers)
- [मेडिकल डेटा प्रोवेनेंस समझाया गया](https://developers.anpheros.com/hi/guides/medical-data-provenance): किसने क्या लिखा, और इसे कैसे रिकॉर्ड करें
- [सहमति और एक्सेस मॉडल](https://developers.anpheros.com/hi/guides/consent)
- [प्रमाणीकरण और OAuth](https://developers.anpheros.com/hi/guides/authentication)
- [सीमाएँ और दर सीमाएँ](https://developers.anpheros.com/hi/guides/limits)
- [विश्वसनीयता, स्थिति और घटनाएँ](https://developers.anpheros.com/hi/guides/reliability): निगरानी, बैकअप, घटना संचार
- [आर्किटेक्चर](https://developers.anpheros.com/hi/guides/architecture)
- [डेवलपर्स के लिए यूरोपीय स्वास्थ्य डेटा स्पेस (EHDS)](https://developers.anpheros.com/hi/guides/ehds-for-developers)