सामग्रीमा जानुहोस्
लगइन
एप डाउनलोड गर्नुहोस्
Bağlayıcı metin TürkçedirBu çeviri bilgilendirme amaçlıdır. Türkçe metni açın.

1.9

CORENTA — डेटा भण्डारण र निष्कासन नीति

यो अनुवाद जानकारीका लागि मात्र उपलब्ध गराइएको हो; कानुनी रूपमा बाध्यकारी पाठ टर्की भाषाको पाठ हो।

खाता नभएका क्लाइन्टलाई मेटाउने: क्लिनिकका एडमिनले गरेको मेटाउने कार्यलाई अनुरोध मानिन्छ; अभिलेख तुरुन्तै सक्रिय सूचीबाट हटाइन्छ र 30 दिनपछि पहिचान/सम्पर्क विवरण र क्लाइन्टका स्वास्थ्य क्षेत्र (रक्त समूह, एलर्जी, दीर्घकालीन अवस्था, औषधि) मेटाइन्छन्/खाली गरिन्छन् (हेर्नुहोस् 5.0)। तलको सामान्य खाता मेटाउने विवरणलाई यस विशेष दायराभित्र क्लाइन्टको पङ्क्ति स्थायी रूपमा मेटाउनैपर्ने दायित्वका रूपमा व्याख्या गरिँदैन। एनामनेसिस, मापन, सेसन नोट र वित्तीय अभिलेख आफ्नै भण्डारण प्रावधानको अधीनमा रहन्छन्।

लागू हुने / अन्तिम पटक अद्यावधिक मिति: 19 अक्टोबर 2026 संस्करण: 1.9 डेटा नियन्त्रक / प्रकाशक: Mertcan Demir — "Teta Studio" व्यापारिक नाममा सञ्चालित एकल स्वामित्वको व्यवसाय

परिवर्तन लग

  • 1.9 — 19 अक्टोबर 2026: भाग 14 को "टर्कीमा मात्र" भन्ने अभिव्यक्तिलाई विश्वव्यापी सेवासँग बदलियो; भण्डारण अवधि परिवर्तन भएनन्।
  • 1.8 — 19 अक्टोबर 2026: प्रकाशन संस्करण; लागू हुने मिति 19 अक्टोबर 2026। भाग 4 मा क्लिनिक समूहका सन्देश र टिमको समीक्षाका लागि छुट्याइएका सन्देश प्रतिलिपिको पङ्क्ति (क्रम 12) थपियो; भाग 7 को आवधिक निष्कासन सूची त्यसअनुसार विस्तार गरियो; 1.3 को तालिकाबाट खाली रहेका MERSİS र KEP विवरण हटाइए।
  • 1.7 — 11 अक्टोबर 2026: 11 अक्टोबर 2026 को अनुपालन समीक्षाअनुसार (F01, F02, F08, F11, F13, F19, F21): §11 को "Supabase/Frankfurt विदेश स्थानान्तरण होइन" भन्ने अभिव्यक्ति हटाइयो र विदेश स्थानान्तरणको खण्ड कानून नं. 6698 को धारा 9 को 2024 पछिको स्वरूपअनुसार लेखियो (मानक सम्झौता अझै हस्ताक्षर भएका छैनन्); स्वास्थ्य/क्लिनिक/वित्तीय अभिलेखका लागि "अज्ञात" भन्ने अभिव्यक्तिलाई व्यक्तिसँगको सम्बन्ध विच्छेद गरिएको सीमित भण्डारणका रूपमा सच्याइयो (सेसन नोटको स्वतन्त्र पाठ परिवर्तन गरिँदैन); सहमतिको प्रमाणको पङ्क्तिको कानुनी आधार धारा 5/2-e का रूपमा सच्याइयो (गलत धारा 20/2 को सन्दर्भ हटाइयो); अर्ली एक्सेस फारमको पङ्क्ति सूचना र व्यावसायिक सन्देशको सहमति छुट्याइएअनुसार अद्यावधिक गरियो; स्वचालित निष्कासन नभएका वर्गका लागि 6 महिनाको आवधिक निष्कासनको सिद्धान्त थपियो; पहिचान विवरणलाई एकल स्वामित्वको व्यवसायका रूपमा सच्याइयो; VERBİS खण्ड 2025 का बोर्डका निर्णयअनुसार लेखियो।
  • 1.6 — 10 अक्टोबर 2026: Expo (Expo Push Notification Service) लाई उप-प्रशोधक/प्रशोधकका अभिलेखबाट हटाइयो; पुस नोटिफिकेसन Apple (APNs) र Google (FCM) मार्फत मात्र पठाइन्छन्, Expo/EAS एप बनाउने औजार मात्र हो र अन्तिम प्रयोगकर्ताको डेटा प्रशोधन गर्दैन।
  • 1.5 — 10 अक्टोबर 2026: Google Analytics छनोटसम्बन्धी अभिव्यक्ति हटाइयो; तेस्रो पक्षको एनालिटिक्स प्रयोग नगरिने र पुस प्रशोधक को हुन् भन्ने स्पष्ट गरियो।
  • 1.4 — 4 अक्टोबर 2026: हालको पाठलाई स्वीकृत संस्करणका रूपमा स्थिर गरियो। यस संस्करणमा यी कुरा मात्र समावेश गरिए: खाता मेटाउने (पहुँच तुरुन्तै बन्द हुन्छ, व्यक्तिगत डेटा मेटिन्छ/अज्ञात बनाइन्छ, कानुनी रूपमा राख्नुपर्ने भुक्तानी अभिलेख पहिचानरहित रूपमा राखिन्छन्; फिर्ता लिने अवधि छैन); 30 दिनपछि क्लाइन्टका स्वास्थ्य क्षेत्र मेटाउने; 7 दिनको अनाथ रसिद अवधि; सपोर्ट मोडमा क्लाइन्टको सम्पर्क गोप्य रहने; पहिचानरहित सर्भर-पक्षीय मापन; सेवा इमेल र Google Workspace; पुस प्रशोधक; सपोर्ट ठेगाना; बजार (टर्की)।
  • 1.3 — 7 जुलाई 2026 (4 अगस्ट 2026 को अद्यावधिक): अघिल्लो संस्करण।

डेटा नियन्त्रक / डेटा प्रशोधकको हैसियतसम्बन्धी महत्त्वपूर्ण टिप्पणी: यो डेटा भण्डारण र निष्कासन नीति ("नीति") ले "Teta Studio" व्यापारिक नाममा एकल स्वामित्वको व्यवसायका रूपमा कार्यरत Mertcan Demir ("Corenta", "Teta Studio", "कम्पनी") ले विकास र सञ्चालन गरेको Corenta सफ्टवेयर सेवा ("सेवा" वा "एप") अन्तर्गत प्रशोधन गरिने व्यक्तिगत डेटा कति अवधिसम्म राखिन्छ, यी अवधि निर्धारण गर्दा आधार मानिने मापदण्ड, र भण्डारण अवधि सकिएमा वा प्रशोधनको कारण नरहेमा यी डेटा कुन विधिले मेटाइन्छन्, नष्ट गरिन्छन् वा अज्ञात बनाइन्छन् भन्ने कुरा नियमन गर्छ।

यो नीति कानून नं. 6698 व्यक्तिगत डेटा संरक्षण कानून ("KVKK"), व्यक्तिगत डेटा मेटाउने, नष्ट गर्ने वा अज्ञात बनाउनेसम्बन्धी नियमावली ("नियमावली") र सम्बन्धित अन्य कानूनको ढाँचाभित्र तयार गरिएको हो र Corenta को व्यक्तिगत डेटा प्रशोधन सूचीको अभिन्न अंग हो। यो नीति डेटा प्रशोधनका उद्देश्य र कानुनी आधार विस्तृत रूपमा व्याख्या गरिएको सम्बन्धित सूचना पाठ/गोपनीयता नीतिसँगै पढ्नुपर्छ; यो कागजातले भण्डारण अवधि र निष्कासनका प्रक्रिया मात्र नियमन गर्छ, KVKK धारा 10 अन्तर्गतको सूचना दिने दायित्व एक्लै पूरा गर्ने उद्देश्य राख्दैन।

1. उद्देश्य र दायरा

1.1. उद्देश्य

यस नीतिको उद्देश्य Corenta ले प्रशोधन गर्ने व्यक्तिगत डेटा प्रशोधन गरिएको उद्देश्यका लागि आवश्यक अधिकतम अवधि निर्धारण गर्ने मापदण्ड, कानूनमा तोकिएका अवधिको प्रयोग, र भण्डारण अवधि सकिएका व्यक्तिगत डेटा मेटाउने, नष्ट गर्ने वा अज्ञात बनाउनेसम्बन्धी प्रक्रिया र सिद्धान्त व्याख्या गर्नु हो। यो नीति KVKK धारा 5, धारा 6, धारा 7, धारा 10, धारा 11 र धारा 12 का प्रावधान र नियमावलीका सम्बन्धित धाराका आधारमा तयार गरिएको हो।

1.2. दायरा र भूमिकाको विभाजन — महत्त्वपूर्ण चेतावनी

यो नीतिले Corenta ले दुई फरक हैसियतमा डेटा प्रशोधन गर्ने दुई छुट्टै क्षेत्र समेट्छ; यो विभाजन नीतिभरि सुसङ्गत रूपमा लागू हुन्छ र भण्डारण अवधिको तालिकाको व्याख्यामा प्रत्यक्ष असर गर्छ:

(a) कर्पोरेट वेबसाइटको सन्दर्भ (corenta.app — अर्ली एक्सेस/डेमो अनुरोध फारम): उत्पादनमा रुचि देखाउने सम्भावित व्यवसायहरूले अर्ली एक्सेस आवेदन फारममार्फत पठाएका व्यक्तिगत डेटाका सम्बन्धमा Corenta/Teta Studio, KVKK धारा 3 बमोजिम प्रत्यक्ष डेटा नियन्त्रकका रूपमा काम गर्छ।

(b) SaaS उत्पादनको सन्दर्भ (app.corenta.app): Corenta प्लेटफर्मलाई सदस्यतामार्फत प्रयोग गर्ने क्लिनिकल पिलाटेस, फिजियोथेरापी, रिफर्मर, वेलनेस/मसाज र योग केन्द्रहरूले ("Tenant", "व्यवसाय" वा "क्लिनिक") आफ्ना क्लाइन्टका ("डेटा धनी क्लाइन्ट") रूपमा प्लेटफर्ममा प्रविष्ट गरेका व्यक्तिगत डेटा (सम्पर्क विवरण, एनामनेसिस, सेसन नोट, अपोइन्टमेन्ट/प्याकेज डेटा आदि) का सम्बन्धमा क्लिनिक, KVKK धारा 3 बमोजिम डेटा नियन्त्रक हो; Corenta/Teta Studio भने डेटा प्रशोधकका रूपमा मात्र, क्लिनिकको निर्देशनअनुसार प्राविधिक पूर्वाधार सेवा दिन्छ। क्लाइन्टलाई सूचना दिने दायित्व, स्पष्ट सहमति लिने कार्य र क्लाइन्टको डेटाको अन्तिम भण्डारण/निष्कासनसम्बन्धी निर्णय क्लिनिकको कानुनी जिम्मेवारी हो। Corenta ले यी दायित्व पूरा गर्ने कार्यलाई उत्पादनभित्र (सहमति अभिलेख गर्ने संयन्त्र consent_logs, मोबाइलको KVKK स्वीकृति स्क्रिन kvkk.tsx, लेखा परीक्षण ट्रेल) प्राविधिक रूपमा सजिलो बनाउँछ, तर क्लिनिकको KVKK अनुपालन दायित्व हस्तान्तरण गर्दैन वा आफूमा लिँदैन। यस सन्दर्भका लागि यस नीतिमा व्याख्या गरिएका भण्डारण अवधिले Corenta ले डेटा प्रशोधकका रूपमा आफ्नो पूर्वाधारमा यी डेटा वास्तवमा कति समय राख्छ भन्ने देखाउँछन्; अन्तिम निष्कासनको निर्णय र अवधि क्लिनिकको निर्देशन र त्यसमा लागू हुने कानूनको ढाँचाभित्र निर्धारण हुन सक्छ।

यो नीतिले Corenta का कर्मचारी, व्यावसायिक साझेदार र आपूर्तिकर्ताका व्यक्तिगत डेटाको भण्डारण/निष्कासन प्रक्रियालाई पनि सामान्य सिद्धान्तका हिसाबले समेट्छ; तर नीतिको मुख्य केन्द्र माथिका (a) र (b) खण्डमा परिभाषित व्यवसाय/क्लाइन्टको डेटा हो।

1.3. डेटा नियन्त्रक / डेटा प्रशोधकको विवरण

डेटा नियन्त्रकMertcan Demir — "Teta Studio" व्यापारिक नाममा सञ्चालित एकल स्वामित्वको व्यवसाय (छुट्टै कानुनी व्यक्तित्व छैन) · कर नं. 2771408706
उत्पादनCorenta
सम्पर्कhello@corenta.app (सामान्य सम्पर्क र KVKK आवेदन) · सपोर्ट: support@corenta.app
कर्पोरेट वेबसाइटcorenta.app
एप/उत्पादनको ठेगानाapp.corenta.app
VERBİS दर्तायस पाठको मितिसम्म दर्ता छैन; दायित्व बोर्डका 2025/1572 र 2025/2393 का मापदण्डअनुसार मूल्याङ्कन गरिँदै छ (हेर्नुहोस् भाग 12)

1.4. आधार कानून

  • कानून नं. 6698 व्यक्तिगत डेटा संरक्षण कानून,
  • व्यक्तिगत डेटा मेटाउने, नष्ट गर्ने वा अज्ञात बनाउनेसम्बन्धी नियमावली (28.10.2017 मिति र 30224 नम्बरको आधिकारिक राजपत्र),
  • व्यक्तिगत डेटा मेटाउने, नष्ट गर्ने वा अज्ञात बनाउनेसम्बन्धी मार्गदर्शन र व्यक्तिगत डेटा संरक्षण बोर्ड ("बोर्ड") का निर्णय,
  • कानून नं. 6102 टर्की व्यापारिक संहिता (व्यापारिक खाता र कागजात राख्ने),
  • कानून नं. 213 कर प्रक्रिया कानून (वित्तीय अभिलेख राख्ने),
  • सम्बन्धित अन्य क्षेत्रगत कानून (लागू हुने हदसम्म स्वास्थ्य सेवा प्रदानसम्बन्धी कानूनसमेत)।

2. परिभाषाहरू

शब्दपरिभाषा
व्यक्तिगत डेटापहिचान भएको वा पहिचान गर्न सकिने प्राकृतिक व्यक्तिसँग सम्बन्धित कुनै पनि जानकारी (KVKK धारा 3/1-d)।
विशेष प्रकृतिको व्यक्तिगत डेटास्वास्थ्य डेटासहित KVKK धारा 6 मा उल्लिखित, थाहा भएमा सम्बन्धित व्यक्तिमाथि भेदभाव वा हानि निम्त्याउन सक्ने प्रकृतिका डेटा।
डेटा नियन्त्रकव्यक्तिगत डेटा प्रशोधनका उद्देश्य र माध्यम निर्धारण गर्ने, डेटा अभिलेख प्रणालीको स्थापना र व्यवस्थापनका लागि जिम्मेवार प्राकृतिक/कानुनी व्यक्ति।
डेटा प्रशोधकडेटा नियन्त्रकले दिएको अधिकारका आधारमा उसको तर्फबाट व्यक्तिगत डेटा प्रशोधन गर्ने प्राकृतिक/कानुनी व्यक्ति।
अभिलेख माध्यमव्यक्तिगत डेटा स्वचालित वा गैर-स्वचालित तरिकाले प्रशोधन गरिने कुनै पनि माध्यम (यहाँ: Supabase (Frankfurt, EU) मा होस्ट गरिएको डेटाबेस, एपभित्रको भण्डारण, ब्याकअप)।
मेटाउनेव्यक्तिगत डेटालाई सम्बन्धित प्रयोगकर्ताका लागि कुनै पनि हालतमा पहुँचयोग्य र पुनः प्रयोगयोग्य नहुने बनाउने प्रक्रिया।
नष्ट गर्नेव्यक्तिगत डेटालाई कसैले पनि कुनै पनि हालतमा पहुँच गर्न, फिर्ता ल्याउन र पुनः प्रयोग गर्न नसक्ने बनाउने प्रक्रिया।
अज्ञात बनाउनेव्यक्तिगत डेटालाई अन्य डेटासँग मिलाए पनि कुनै पनि हालतमा पहिचान भएको वा पहिचान गर्न सकिने प्राकृतिक व्यक्तिसँग जोड्न नसकिने बनाउने कार्य।
भण्डारण अवधिव्यक्तिगत डेटालाई सम्बन्धित कानूनमा तोकिएको वा प्रशोधन गरिएको उद्देश्यका लागि आवश्यक अवधिभर सुरक्षित राख्ने कार्य।
आवधिक निष्कासनकानूनमा तोकिएका सर्तअनुसार, आफैँ र नियमित अन्तरालमा गरिने मेटाउने, नष्ट गर्ने वा अज्ञात बनाउने प्रक्रिया।
Tenant / व्यवसाय / क्लिनिकCorenta प्लेटफर्ममा छुट्टै खातासँग मेल खाने, डेटा अन्य व्यवसायबाट तार्किक रूपमा अलग गरिएको, क्लिनिकल पिलाटेस/फिजियोथेरापी/रिफर्मर/वेलनेस/योग केन्द्रको भाडावाल इकाइ।
निष्कासनव्यक्तिगत डेटा मेटाउने, नष्ट गर्ने वा अज्ञात बनाउने प्रक्रियाको साझा नाम।

3. भण्डारण र निष्कासन अवधि निर्धारण गर्ने मापदण्ड (KVKK धारा 5, धारा 6)

3.1. भण्डारण आवश्यक पार्ने कारण

Corenta भित्र व्यक्तिगत डेटा सम्बन्धित कानूनमा स्पष्ट रूपमा तोकिएको अवधिसम्म वा प्रशोधन गरिएको उद्देश्यका लागि आवश्यक अवधिसम्म मात्र सुरक्षित राखिन्छ। भण्डारण अवधि निर्धारण गर्दा तलका मापदण्डलाई आधार मानिन्छ:

  1. कानुनी रूपमा राख्नुपर्ने दायित्व छ? (जस्तै टर्की व्यापारिक संहिता र कर प्रक्रिया कानून अन्तर्गत वित्तीय अभिलेखका लागि न्यूनतम भण्डारण अवधि।)
  2. डेटा कुन उद्देश्यले प्रशोधन गरिएको हो र त्यो उद्देश्य अझै मान्य छ? (KVKK धारा 5/2 — उद्देश्यमा सीमित रहने सिद्धान्त।)
  3. सम्झौता गर्न/कार्यान्वयन गर्न आवश्यक छ? (जस्तै सदस्यता/सेवा सम्बन्ध जारी रहँदा अपोइन्टमेन्ट र प्याकेज डेटा।)
  4. कुनै अधिकार स्थापना गर्न, प्रयोग गर्न वा संरक्षण गर्न (सम्भावित कानुनी विवादमा प्रमाणको माध्यमका रूपमा) आवश्यक छ? (दायित्वसम्बन्धी संहिताका सामान्य हदम्यादलाई ध्यानमा राखेर।)
  5. डेटा धनीको स्पष्ट सहमति छ र त्यो सहमति अझै मान्य छ?
  6. Corenta वा क्लिनिकको वैध हित छ? (जस्तै सुरक्षा लग, ठगी/दुरुपयोगको पहिचान।)
  7. डेटा विशेष प्रकृतिको (स्वास्थ्य) डेटाको वर्गमा पर्छ? यस्तो अवस्थामा KVKK धारा 6 बमोजिम थप कडा पहुँच सीमा र औचित्य लागू हुन्छ; भण्डारण अवधि कहिल्यै उद्देश्यबाहिर लम्ब्याइँदैन।

माथिका कुनै पनि मापदण्डले कुनै निश्चित व्यक्तिगत डेटाका लागि भण्डारण आवश्यक नपारेमा, डेटा तुरुन्तै मेटाइन्छ, नष्ट गरिन्छ वा अज्ञात बनाइन्छ।

3.2. निष्कासन आवश्यक पार्ने कारण

तलका अवस्थामा व्यक्तिगत डेटा सम्बन्धित व्यक्तिको अनुरोधमा वा Corenta/क्लिनिकले आफैँ मेटाउँछ, नष्ट गर्छ वा अज्ञात बनाउँछ:

a) प्रशोधनको आधार बनेका कानुनी प्रावधान परिवर्तन वा खारेज भएमा, b) प्रशोधन वा भण्डारण आवश्यक पार्ने उद्देश्य नरहेमा, c) स्पष्ट सहमतिमा आधारित प्रशोधनमा डेटा धनीले सहमति फिर्ता लिएमा, d) KVKK धारा 11 अन्तर्गतका अधिकारको ढाँचाभित्र डेटा धनीले मेटाउन/नष्ट गर्न अनुरोध गरेमा र त्यो अनुरोध उपयुक्त ठहरिएमा (खाता मेटाउने अनुरोध), e) व्यक्तिगत डेटाको भण्डारण अवधि सकिएमा र भण्डारण आवश्यक पार्ने कुनै कानुनी कारण नरहेमा, f) सम्झौता कहिल्यै नभएमा, अमान्य भएमा, अन्त्य गरिएमा वा सम्झौताबाट फिर्ता भएमा, g) खाता मेटाउने अनुरोध यस नीतिको धारा 5 मा उल्लिखित प्रक्रियाभित्र अन्तिम रूपमा पूरा भएमा।

4. डेटा वर्ग, भण्डारण अवधि र निष्कासन विधिको तालिका

तलको तालिकाले Corenta को पूर्वाधारमा प्रशोधन गरिने मुख्य व्यक्तिगत डेटा वर्ग, भण्डारण अवधि, त्यसको कारण र अवधि सकिएपछि लागू हुने निष्कासन विधि देखाउँछ। स्पष्ट रूपमा अन्यथा नभनिएसम्म सामान्य नियम यो हो: "सम्बन्धित खाता/अभिलेख सक्रिय रहुन्जेल + खाता मेटाउने अनुरोध प्रशोधनमा लिइएदेखि 30 दिन।" तालिकालाई भाग 5 मा व्याख्या गरिएको खाता मेटाउने प्रवाहसँगै पढ्नुपर्छ। केही वर्गका लागि यस प्रवाहको 30 दिनको अन्त्यको चरण DELETE (स्थायी रूपमा मेटाउने) होइन, अज्ञात बनाउने हो — सम्बन्धित पङ्क्ति र भाग 6.2 मा यो भिन्नता स्पष्ट रूपमा उल्लेख गरिएको छ।

<div style="overflow-x:auto">

#डेटाको वर्गउदाहरण डेटा क्षेत्रभण्डारण अवधिकारण / कानुनी आधारनिष्कासनको विधि
1पहिचान र सम्पर्क डेटा (प्रयोगकर्ता/स्पेसलिस्ट/क्लाइन्ट)नाम-थर, इमेल, फोन, जन्ममिति, प्रोफाइल जानकारीखाता/क्लाइन्ट अभिलेख सक्रिय रहुन्जेल + मेटाउने अनुरोधपछि 30 दिनKVKK धारा 5 — सम्झौता गर्ने/कार्यान्वयन गर्ने; सेवामा पहुँच उपलब्ध गराउने। क्लाइन्टको डेटाका सम्बन्धमा डेटा नियन्त्रक क्लिनिक हो।चरण-1 सफ्ट-डिलिट → चरण-2 स्थायी रूपमा मेटाउने (हेर्नुहोस् धारा 5)
2स्वास्थ्य डेटा / एनामनेसिस फारम (anamnesis_forms)स्वास्थ्य इतिहास, दुखाइ/गुनासोको जानकारी, प्रतिनिर्देशन (contraindication)क्लाइन्ट अभिलेख सक्रिय रहुन्जेल + मेटाउने अनुरोधपछि 30 दिन। anamnesis_forms का लागि प्रणालीमा DELETE (मेटाउने) नीति परिभाषित छैन — दैनिक प्रयोगमा कसैले पनि (प्रशासनिक प्रयोगकर्तासमेत) अभिलेख म्यानुअल रूपमा मेटाउन सक्दैन। 30 दिनको अवधिको अन्त्यमा अभिलेखलाई DELETE गरिँदैन; व्यक्तिसँगको सम्बन्ध विच्छेद गरिन्छ: व्यक्तिसँगको सम्बन्ध (client_id) डेटाबेस स्तरमा फिर्ता ल्याउन नसकिने गरी विच्छेद गरिन्छ (FK ON DELETE SET NULL) र प्रश्नावलीको सामग्री (answers) र संलग्न फाइलको सन्दर्भ (attached_files) लाई अज्ञात चिन्हले बदलिन्छ; संलग्न फाइल आफैँ पनि Storage बाट छुट्टै स्वचालित रूपमा मेटाइन्छ (हेर्नुहोस् क्रम 11)।KVKK धारा 6 — विशेष प्रकृतिको डेटा; क्लिनिकको सेवा दिन र सम्भावित चिकित्सकीय/कानुनी जिम्मेवारी प्रमाणित गर्न आवश्यक (डेटा नियन्त्रक: क्लिनिक); क्लिनिकको अभिलेख राख्ने दायित्वका कारण क्लिनिकको अभिलेख आफैँ (क्लाइन्टसँगको सम्बन्ध विच्छेद गरिएको रूपमा) tenant मा सीमित पहुँचसहित राखिँदै रहन्छ; यो अभिलेख अज्ञात मानिँदैन। पहुँच सम्बन्धित क्लाइन्ट/तोकिएको स्पेसलिस्ट/tenant एडमिनमा सीमित छ (RLS)।चरण-1 सफ्ट-डिलिट (पहुँच बन्द) → चरण-2 अज्ञात बनाउने (anonymize_user_relations() RPC, service-role मात्र) + FK मार्फत व्यक्तिसँगको सम्बन्ध विच्छेद
3सेसन नोट (session_notes)स्पेसलिस्टले सेसनका क्रममा प्रविष्ट गरेका क्लिनिकल नोटमाथिकै जस्तै। नोट पठाएपछि (submitted_at क्षेत्र भरिएपछि) UPDATE/DELETE बाट परिवर्तन गर्न वा मेटाउन सकिँदैन (append-only संरचना, डेटाबेस स्तरमा लागू) र खाता मेटाउने प्रक्रियामा पनि यो सामग्री परिवर्तन गरिँदैन। चरण-2 मा व्यक्तिसँगका सम्बन्ध (client_id, specialist_id) मात्र FK ON DELETE SET NULL बाट विच्छेद गरिन्छन्; append-only ट्रिगरमा यही एउटा उद्देश्यका लागि साँघुरो अपवाद परिभाषित छ (सम्बन्धका कोलमलाई NULL बनाउन मात्र अनुमति दिन्छ, नोटको सामग्रीमा एउटा अक्षर पनि परिवर्तन गर्न दिँदैन)। परिणाम: नोटको मुख्य भागको स्वतन्त्र पाठमा नाम/पहिचान जानकारी रहन सक्ने भएकाले यी अभिलेख खाता मेटाएपछि अज्ञात मानिँदैनन्; क्लिनिकको अभिलेख राख्ने दायित्वको अवधिभर सीमित पहुँचसहित राखिन्छन् र अवधि सकिएपछि निष्कासन गरिन्छन्। मेटाउने बेला स्वतन्त्र पाठ सफा गर्ने कुरा छुट्टै मूल्याङ्कन गरिने उत्पादनसम्बन्धी निर्णय हो।KVKK धारा 6 — विशेष प्रकृतिको डेटा; क्लिनिकल अभिलेखको अखण्डता र सम्भावित चिकित्सकीय जिम्मेवारीका अवस्थामा प्रमाणको माध्यम। परिवर्तन गर्न नसकिने व्यवस्था अभिलेखको विश्वसनीयता जोगाउन सचेत रूपमा गरिएको डिजाइन छनोट हो; खाता मेटाएपछि पनि क्लिनिकल अभिलेखको अखण्डता यही सिद्धान्तले जोगाइन्छ।उस्तै; append-only सीमा कायम राख्दै व्यक्तिसँगको सम्बन्ध मात्र FK बाट विच्छेद गरिन्छ — नोटको सामग्री कुनै पनि चरणमा मेटाइँदैन वा परिवर्तन गरिँदैन
4मापन डेटा (measurements)शरीरको मापन, प्रगति ट्र्याकिङजस्ता क्लिनिकल मापनमाथिकै जस्तै। चरण-2 मा अभिलेख मेटाइँदैन; व्यक्तिसँगको सम्बन्ध विच्छेद गरिन्छ: व्यक्तिसँगको सम्बन्ध (client_id) FK ON DELETE SET NULL बाट विच्छेद गरिन्छ, स्वतन्त्र पाठको notes क्षेत्र (नाम/पहिचान हुन सक्ने) NULL बनाइन्छ; सङ्ख्यात्मक/वर्गीय मापनका मान (तौल, VAS, निद्रा आदि) tenant को व्यक्तिसँगको सम्बन्ध विच्छेद गरिएको क्लिनिकल अभिलेखका रूपमा राखिँदै रहन्छन् (साना व्यवसायमा मापनको शृङ्खलाले व्यक्तिलाई फेरि पहिचान गर्न पुग्न सक्ने भएकाले अज्ञात मानिँदैन)।KVKK धारा 6 — विशेष प्रकृतिको डेटा; सेवा (प्रगति ट्र्याकिङ) कार्यान्वयन गर्न आवश्यक (डेटा नियन्त्रक: क्लिनिक); सङ्ख्यात्मक मापन शृङ्खला क्लिनिकको अभिलेख राख्ने दायित्व र प्रगति ट्र्याकिङको अखण्डताका लागि व्यक्तिसँगको सम्बन्ध विच्छेद गरिएको रूपमा सुरक्षित राखिन्छ।चरण-1 सफ्ट-डिलिट → चरण-2 अज्ञात बनाउने (anonymize_user_relations() RPC) + FK मार्फत व्यक्तिसँगको सम्बन्ध विच्छेद
5अपोइन्टमेन्ट, प्याकेज र भुक्तानी डेटाअपोइन्टमेन्टका मिति, प्याकेज/सेसनको बाँकी, रद्दका अभिलेख, भुक्तानी/सङ्कलनका अभिलेख (payments), उपस्थितिका अभिलेख (attendance)खाता सक्रिय रहुन्जेल + मेटाउने अनुरोधपछि 30 दिन। अपोइन्टमेन्ट अभिलेख आफैँ (appointments.client_id) डिजाइनअनुसार पहिल्यै nullable छ; मेटाएपछि व्यक्तिसँगको सम्बन्ध विच्छेद गरिन्छ र अपोइन्टमेन्टको इतिहास (मिति/सेवा/स्थिति) tenant को अभिलेखका रूपमा रहन्छ। भुक्तानी अभिलेख (payments) र उपस्थितिका अभिलेख (attendance) लाई पनि त्यसै गरी DELETE गरिँदैन; व्यक्तिसँगको सम्बन्ध विच्छेद गरिन्छ: व्यक्तिसँगको सम्बन्ध (client_id) FK ON DELETE SET NULL बाट विच्छेद गरिन्छ; भुक्तानीमा स्वतन्त्र पाठको नोट, रिफन्डको कारण र रसिदको तस्बिरको सन्दर्भ (नाम हुन सक्ने) NULL बनाइन्छ र रसिदको फाइल आफैँ Storage बाट छुट्टै स्वचालित रूपमा मेटाइन्छ (हेर्नुहोस् क्रम 11), रकम/मिति/स्थितिको जानकारी रहन्छ; उपस्थितिमा स्वतन्त्र पाठको notes NULL बनाइन्छ, आयो/आएन भन्ने स्थिति रहन्छ। client_packages (प्याकेजको बाँकी) तालिकामा प्रत्यक्ष व्यक्तिगत/स्वतन्त्र पाठको डेटा कोलम नभएकाले यो तालिका परिवर्तन नगरी tenant को अभिलेखका रूपमा रहिरहन्छ।KVKK धारा 5 — सम्झौताको कार्यान्वयन; साथै विवादको अवस्थामा (प्याकेजको कमाइ/शुल्कसम्बन्धी असहमति आदि) प्रमाणको माध्यम हुन सक्छ; क्लिनिकको अभिलेख राख्ने दायित्वले यी डेटा व्यक्तिसँगको सम्बन्ध विच्छेद गरी राख्न आवश्यक पार्छ।चरण-1 सफ्ट-डिलिट → चरण-2: अपोइन्टमेन्ट/प्याकेजको अभिलेख रहन्छ, भुक्तानी र उपस्थितिका अभिलेख अज्ञात बनाउने (anonymize_user_relations() RPC) + FK मार्फत व्यक्तिसँगको सम्बन्ध विच्छेदद्वारा प्रशोधन गरिन्छन्; client_packages का लागि परिवर्तन आवश्यक छैन (PII कोलम छैन)
6सदस्यता/कारोबारको मेटा डेटा (IAP)प्लानको नाम, सदस्यताको स्थिति, कारोबारको मिति, IAP कारोबार/सदस्यताको मेटा डेटाकम्पनीको आफ्नै लेखा/वित्तीय कानूनको दायित्वअन्तर्गतका अभिलेखका लागि टर्की व्यापारिक संहिता धारा 82 र कर प्रक्रिया कानून धारा 253 बमोजिम तोकिएको कानुनी भण्डारण अवधिभर (सामान्य अभ्यासमा कम्तीमा 10 वर्षसम्म)कानून नं. 6102 TTK धारा 82, कानून नं. 213 VUK धारा 253 — कानुनी रूपमा राख्नुपर्ने दायित्व। महत्त्वपूर्ण स्पष्टीकरण: Corenta को भुक्तानी मोडेल Apple/Google एपभित्रको खरिद (IAP) मार्फत मात्र चल्छ; अन्तिम उपभोक्ताको बिलिङ/रसिद Apple/Google ले जारी गर्छन् र राख्छन्, Corenta ले यी कागजात बनाउँदैन वा राख्दैन। Corenta को IAP मोडेलमा कार्ड/भुक्तानी माध्यमको जानकारी Apple/Google ले प्रशोधन गर्छन् र राख्छन्; Corenta को आफ्नै पूर्वाधारमा (डेटाबेस, लग) यस्तो भुक्तानी माध्यमको जानकारी राखिएको पाइएको छैन। Corenta ले प्रमाणित IAP सदस्यताको मेटा डेटा (प्लानको नाम, कारोबारको मिति, सदस्यताको स्थिति) मात्र TTK/VUK मा तोकिएको कानुनी अवधिभर राख्छ। कम्पनीले यसबाहेक सामान्य लेखा खाता र कागजात पनि राखेमा, ती अभिलेख पनि उही TTK/VUK अवधिको दायरामा तर यस नीतिको विषय बनेका व्यक्तिगत डेटाका वर्गभन्दा अलग, आफ्नै वित्तीय कानुनी व्यवस्थाको अधीनमा रहने दायरा बनाउँछन्; यो कागजातले त्यस छुट्टै दायराको अस्तित्व वा सामग्रीबारे दाबी गर्दैन। यो वर्ग खाता मेटाउने अनुरोधबाट प्रभावित हुँदैन; खाता मेटाइए पनि सम्बन्धित कानुनी अवधि नसकिउन्जेल, प्रशोधनको उद्देश्यबाट अलग गरी र कानुनी दायित्व पूरा गर्ने उद्देश्यमा मात्र सीमित पहुँचसहित छुट्टै सुरक्षित राखिन्छ।कानुनी अवधिको अन्त्यमा मेटाउने वा अज्ञात बनाउने
7लेखा परीक्षण ट्रेलका अभिलेख (audit_logs)प्रणालीभित्रका महत्त्वपूर्ण कार्यहरू (impersonation, अधिकार परिवर्तन, डेटामा पहुँच आदि) को अभिलेखअभिलेख बनेको मितिदेखि 2 वर्षसम्म राखिन्छ — सुरक्षा घटनाको पहिचान, अनधिकृत पहुँचको अनुसन्धान र दुरुपयोग रोकथामका लागि वैध हित र सम्भावित कानुनी विवादमा प्रमाणको दायित्वको ढाँचाभित्र निर्धारण गरिएको निश्चित अवधि हो। अवधि सकिएका अभिलेख 6 महिनामा एक पटक गरिने आवधिक निष्कासनबाट मेटाइन्छन्; यो निष्कासन हाल म्यानुअल रूपमा गरिन्छ, तालिकाबद्ध स्वचालित निष्कासन कार्य अझै छैन। खाता मेटाइए पनि यी अभिलेख 2 वर्षको अवधि नसकिउन्जेल छुट्टै सुरक्षित राखिन्छन्।KVKK धारा 5/2-f — वैध हित (सुरक्षा घटनाको पहिचान, अनधिकृत पहुँचको अनुसन्धान, दुरुपयोग रोकथाम) र सम्भावित कानुनी विवादमा प्रमाणको माध्यम हुनु। यी अभिलेख आफ्नो प्रकृतिअनुसार सम्बन्धित व्यक्तिमा सीमित हुँदैनन्, प्रणालीको सुरक्षा/जवाफदेहिताको उद्देश्य पूरा गर्छन्; सम्बन्धित प्रयोगकर्ताको खाता मेटाउने अनुरोधले यी अभिलेख स्वचालित रूपमा मेटाउँदैन।भण्डारण अवधिको अन्त्यमा मेटाउने वा अज्ञात बनाउने (स्वचालित सफाइ संयन्त्र अझै लागू गरिएको छैन)
8सूचना र अनुमतिका अभिलेख (consent_logs)सूचना देखाइएको अभिलेख ("पढें, बुझें"; सहमति होइन), स्वास्थ्य डेटाको सहमति, क्याम्पेन नोटिफिकेसनको अनुमति, पुस अनुमतिका अभिलेख; समय, IP ठेगाना, संस्करणको जानकारी, फिर्ता लिइएको (revoked_at) अभिलेखखाता सक्रिय रहुन्जेल + मेटाउने अनुरोधपछि 30 दिन; यो 30 दिनको अवधिपछि सहमति दिइएको वा फिर्ता लिइएको प्रमाणित गर्ने उद्देश्यले (सम्भावित KVKK उजुरी/निरीक्षणको सम्भावनाविरुद्ध छुट्टै प्रमाण अभिलेखका रूपमा) 5 वर्षसम्म छुट्टै राखिन्छ — वैध हित र प्रमाणको दायित्वको ढाँचाभित्र निर्धारण गरिएको निश्चित अवधि हो। यो 5 वर्षको प्रमाण भण्डारण स्थायी रूपमा मेटाउने चरणमा अभिलेखको व्यक्तिसँगको सम्बन्ध (user_id) FK ON DELETE SET NULL बाट विच्छेद गरेर र IP ठेगाना (ip_address) सफा गरेर व्यक्तिसँगको सम्बन्ध विच्छेद गरिएको प्रमाण अभिलेखका रूपमा व्यवहारमा सम्भव बनाइएको छ; सहमतिको प्रकार, संस्करण र दिइएको/फिर्ता लिइएको समयको जानकारी व्यक्तिभन्दा स्वतन्त्र रूपमा राखिँदै रहन्छ। 5 वर्षको अवधि सकिएका अभिलेख 6 महिनामा एक पटक गरिने आवधिक निष्कासनबाट मेटाइन्छन् (हाल म्यानुअल; तालिकाबद्ध स्वचालित निष्कासन कार्य अझै छैन)।KVKK धारा 5/2-e (अधिकारको स्थापना, प्रयोग वा संरक्षण) र धारा 5/2-f; स्पष्ट सहमति प्रमाणित गर्ने भार डेटा नियन्त्रकमा हुन्छ (बोर्डको सिद्धान्त निर्णय 2026/347); दायित्वसम्बन्धी संहिताका सामान्य हदम्यादसँग मेल खान्छ।खाता स्थायी रूपमा मेटाउने प्रक्रियामा अभिलेखलाई DELETE गरिँदैन; व्यक्तिसँगको सम्बन्ध FK बाट विच्छेद गरिन्छ र IP ठेगाना अज्ञात बनाइन्छ (anonymize_user_relations() RPC) — व्यक्तिसँगको सम्बन्ध विच्छेद गरिएको प्रमाण अभिलेख 5 वर्ष राखिँदै रहन्छ (5 वर्षपछि 6 महिनाको आवधिक निष्कासन; स्वचालित कार्य अझै छैन)
9अर्ली एक्सेस फारमको डेटा (कर्पोरेट वेब)नाम-थर, इमेल, फोन (ऐच्छिक), व्यवसायको नाम, सहर, व्यवसायको प्रकार, स्पेसलिस्ट/प्रशिक्षकको सङ्ख्या, सन्देश/सञ्चालनको समस्याको सामग्री, IP ठेगाना/डिभाइस/ब्राउजर/कुकी जानकारीआवेदनको मूल्याङ्कन र सम्पर्क प्रक्रिया टुङ्गिएदेखि बढीमा 2 वर्ष; यस अवधिभित्र सम्पर्क नभएमा वा प्रक्रिया टुङ्गिएमा अझ छिटो मेटाइन्छ/अज्ञात बनाइन्छ। पारदर्शिताको टिप्पणी: यो अधिकतम अवधिसँग मेल खाने, प्रणालीमा स्वचालित रूपमा चल्ने स्क्यानिङ/मेटाउने संयन्त्र हाल छैन (हेर्नुहोस् टिप्पणी 2 र भाग 7, बुँदा 3) — अवधि कानुनी माथिल्लो सीमा हो; अवधि सकिएका अभिलेख 6 महिनामा एक पटक गरिने आवधिक निष्कासनबाट (हाल म्यानुअल) वा अनुरोधमा मेटाइन्छन्।KVKK धारा 5 — सम्झौता अघिको छलफल (धारा 5/2-c); वैध हित (लक्षित ग्राहक प्रोफाइलसँग मेल खाने मूल्याङ्कन, बजार अनुसन्धान, उत्पादन विकासको इनपुट, साइटको सुरक्षा/कार्यसम्पादन); व्यावसायिक सन्देशको सहमति दिइएको भए कानून नं. 6563 धारा 6 बमोजिम छुट्टै सहमति। व्यावसायिक सन्देशको सहमतिबारे स्पष्टीकरण: फारममा सूचनाका लागि सहमतिको चेकबक्स हुँदैन (KVKK सूचना पाठ A.7; सूचना र सहमति अलग छन्)। व्यावसायिक सन्देशको सहमति छुट्टै र पहिल्यै चिन्ह नलगाइएको बक्सबाट लिइन्छ ("Teta Studio ले Corenta का घोषणा र क्याम्पेन इमेलमार्फत पठाउन म सहमति दिन्छु।"); बक्समा चिन्ह नलगाउँदा आवेदनको मूल्याङ्कनमा असर पर्दैन।मेटाउने वा अज्ञात बनाउने (हाल म्यानुअल/अनुरोधमा लागू)
10पुस नोटिफिकेसनको सहमति/टोकन डेटा र नोटिफिकेसनका अभिलेख (notifications)नोटिफिकेसनको अनुमति दिइएको/अस्वीकार गरिएको अभिलेख, डिभाइसको पुस टोकन (Apple APNs / Google FCM), पठाइएका नोटिफिकेसन आफैँ (शीर्षक/सामग्री/डिप लिङ्क — notifications तालिका)खाता/डिभाइसको अभिलेख सक्रिय रहुन्जेल / नोटिफिकेसनको अनुमति मान्य रहुन्जेल + खाता मेटाउने अनुरोधपछि 30 दिन; प्रयोगकर्ताले अनुमति फिर्ता लिँदा टोकन तुरुन्तै अमान्य बनाइन्छ। पठाइएका नोटिफिकेसनका अभिलेख (notifications) को खाता मेटाएपछि कुनै स्वतन्त्र व्यावसायिक/प्रमाणको मूल्य हुँदैन; त्यसैले स्थायी रूपमा मेटाउने चरणमा खातासँगै पूर्ण रूपमा मेटाइन्छन् (ON DELETE CASCADE) — अज्ञात बनाइँदैन, छुट्टै राखिँदैन। पारदर्शिताको टिप्पणी: खाता सक्रिय रहँदा पनि अमान्य/म्याद सकिएका पुस टोकन छुट्टै स्वचालित र आवधिक रूपमा सफा गरिन्छन् भन्ने संयन्त्र यो नीति तयार गर्दा प्राविधिक रूपमा प्रमाणित गर्न सकिएन; यो कुरा प्रमाणित भएको छैन; प्रमाणित भएमा वा थपिएमा यो नीति अद्यावधिक गरिनेछ।KVKK धारा 5/2-c — सम्झौताको कार्यान्वयन (अपोइन्टमेन्ट सम्झाउनेजस्ता कारोबारसम्बन्धी नोटिफिकेसन); क्याम्पेन नोटिफिकेसनका लागि छुट्टै ऐच्छिक अनुमति।चरण-1 सफ्ट-डिलिट → चरण-2: notifications को अभिलेख खातासँगै पूर्ण रूपमा मेटाइन्छ (DELETE/cascade); खाता सक्रिय रहँदा अमान्य/म्याद सकिएका टोकन छुट्टै सफा गर्ने योजनाबद्ध सुधार हो, यसको स्वचालित प्रयोग हाल प्रमाणित भएको छैन
11संलग्न फाइल (अवतार, भुक्तानीको रसिद, एनामनेसिसको संलग्नक, स्पेसलिस्ट प्रमाणीकरणको कागजात — Supabase Storage)क्यामेरा/ग्यालरीबाट अपलोड गरिएका तस्बिर/कागजातका संलग्नकखाता/tenant सक्रिय रहुन्जेल; खाता स्थायी रूपमा मेटाउने चरणमा प्रयोगकर्ताको प्रोफाइल/एनामनेसिस फोल्डरका फाइल (avatars, anamnesis-attachments, user-data-exports बकेट) र भुक्तानीको रसिदका तस्बिर (payment-receipts बकेट, DB अभिलेखबाट पढिएको फाइल पथमार्फत) स्वचालित रूपमा (best-effort) Storage बाट मेटाइन्छन् — कुनै बकेटमा मेटाउन असफल भएमा त्रुटि लग गरिन्छ, तर यसले अरू बकेटको सफाइ वा खाताका अज्ञात बनाउने/स्थायी रूपमा मेटाउने चरण रोक्दैन। इमानदार सीमा: स्पेसलिस्टको पहिचान/डिप्लोमा प्रमाणीकरणका कागजात (specialist-verification-docs बकेट) यो स्वचालित प्रक्रियामा समावेश छैनन् — यो कागजात प्रयोगकर्ताको होइन, tenant (क्लिनिक) को एकल-स्पेसलिस्ट प्रमाणीकरण प्रक्रियाको हो र डेटाबेसको अभिलेखमा प्रयोगकर्ताको सन्दर्भ बोक्दैन, त्यसैले हालको प्रयोगकर्ता-खाता-मेटाउने प्रवाहसँग जोड्न सकिँदैन; यसको निष्कासन क्लिनिकले tenant स्तरमा आफ्नो खाता/सदस्यता बन्द गर्ने प्रक्रियामा छुट्टै गरिनेछ (हेर्नुहोस् भाग 5.4 र 5.6)KVKK धारा 7 र नियमावली — प्रशोधनको उद्देश्य नरहँदा मेटाउने दायित्व।स्वचालित रूपमा मेटाउने: avatars, anamnesis-attachments, user-data-exports, payment-receipts। specialist-verification-docs का लागि स्वचालित निष्कासन अझै छैन; tenant बन्द गर्ने प्रक्रियामा गरिन्छ, अपवादजनक अनुरोध hello@corenta.app मार्फत म्यानुअल रूपमा मूल्याङ्कन गरिन्छन्
12क्लिनिक समूहका सन्देश र मोडरेसनका अभिलेख (group_messages, group_message_moderation; 18 अक्टोबर 2026 देखि)समूहको सन्देशको पाठ, स्टिकर, सर्वेक्षण र मत, उजुरीको कारण, लुकाउने/मेटाउने/म्युट गर्ने अभिलेख, टिमको समीक्षाका लागि छुट्याइएको लुकाइएको सन्देशको प्रतिलिपिसमूह र क्लिनिकको Corenta खाता रहुन्जेल समूहका सन्देश राखिन्छन्; सदस्यले आफ्नो सन्देश जुनसुकै बेला मेटाउन सक्छ र मेटाइएको सन्देशको पाठ अभिलेखबाट हटाइन्छ। खाता स्थायी रूपमा मेटाउँदा समूहको सदस्यता मेटाइन्छ; समूहमा पहिल्यै पठाइएका सन्देशको पाठ पठाउनेको जानकारी हटाएर समूहमा रहन्छ। टिमको समीक्षाका लागि छुट्याइएको प्रतिलिपि सन्देश लुकाइएको मितिदेखि बढीमा 1 वर्ष राखिन्छ र 6 महिनामा एक पटक गरिने आवधिक निष्कासनमा मेटाइन्छ; यो निष्कासन हाल म्यानुअल रूपमा गरिन्छ, तालिकाबद्ध स्वचालित निष्कासन कार्य अझै छैन। क्लिनिक स्तरमा मेटाउँदा भाग 5.6 लागू हुन्छ।KVKK धारा 5/2-c (समूहमा सहभागिता र सञ्चार); धारा 5/2-f (उजुरी र मोडरेसन, दुरुपयोग रोकथाम)। डेटा नियन्त्रक: क्लिनिक। Corenta ले समूहमा स्वास्थ्यको अभिलेख देखाउँदैन; सन्देश स्वतन्त्र पाठ भएकाले सदस्यलाई स्वास्थ्य जानकारी सेयर नगर्न चेतावनी दिइन्छ।सदस्यले मेटाउँदा: पाठ हटाउने; खाता स्थायी रूपमा मेटाउँदा: पठाउनेसँगको सम्बन्ध विच्छेद; मोडरेसनको प्रतिलिपि: 1 वर्षपछि मेटाउने (6 महिनाको आवधिक निष्कासन, हाल म्यानुअल)

</div>

टिप्पणी 1: माथिको तालिकामा "खाता/tenant सक्रिय रहुन्जेल" भन्ने अभिव्यक्तिले सम्बन्धित क्लिनिकको Corenta सदस्यता जारी रहेको र क्लाइन्टको अभिलेख क्लिनिकले नमेटाएको अवधि जनाउँछ। क्लिनिकले आफ्नो क्लाइन्टको डेटा कहिले मेटाउने भन्ने कुरा क्लिनिकको (डेटा नियन्त्रकका रूपमा) आफ्नै KVKK नीति र क्लाइन्टसँगको सम्बन्धको ढाँचाभित्र निर्धारण हुन्छ; Corenta ले यस प्रक्रियाका लागि प्राविधिक सुविधा उपलब्ध गराउँछ।

टिप्पणी 2: क्रम 7 (लेखा परीक्षण ट्रेलका अभिलेख) को 2 वर्ष र क्रम 8 (सहमतिका अभिलेख) को 5 वर्ष Corenta ले निर्धारण गरेका निश्चित भण्डारण अवधि हुन् (क्रम 6 को TTK/VUK अवधिजस्तो नभई कुनै कानुनी प्रावधानमा प्रत्यक्ष आधारित छैनन्; KVKK धारा 5/2-f को वैध हित र प्रमाणको दायित्वको ढाँचाभित्र निर्धारण गरिएको, आफैँ बाध्यकारी प्रतिबद्धता हो)। यी अवधिको अन्त्यमा प्रणालीमा भण्डारण-अन्त्यको स्वचालित मेटाउने संयन्त्र हाल चलिरहेको छैन — अवधि सकिएपछि मेटाउने/अज्ञात बनाउने प्रक्रिया म्यानुअल रूपमा गरिन्छ, स्वचालन लागू भएपछि यो नीति अद्यावधिक गरिनेछ। क्रम 9 (अर्ली एक्सेस फारमको डेटा) को "बढीमा 2 वर्ष" भन्ने अभिव्यक्ति फरक दायराको हो र आफ्नै पङ्क्तिमा व्याख्या गरिएझैँ छुट्टै कानुनी माथिल्लो सीमा जनाउँछ।

5. खाता मेटाउने प्रक्रिया — सुरुदेखि अन्त्यसम्मको सञ्चालन

KVKK धारा 11 अन्तर्गत डेटा धनीको मेटाउने अनुरोधलाई प्राविधिक रूपमा पूरा गर्न Corenta ले प्रयोगकर्ताको अनुभव र डेटा सुरक्षा/कानुनी प्रमाणको आवश्यकताबीच सन्तुलन राख्ने दुई चरणको मेटाउने संरचना लागू गर्छ: तत्काल सफ्ट-डिलिट (soft-delete) र त्यसपछि 30 दिनपछि स्थायी रूपमा मेटाउने।

5.0. 4 अक्टोबर 2026 को परिवर्तन — 5.1–5.7 सँग बाझिएमा यो धारा प्राथमिकतामा पर्छ

खाता मेटाउने (4 अक्टोबर 2026 देखि): मेटाउने अनुरोध स्वीकृत भएपछि खातामा पहुँच तुरुन्तै बन्द हुन्छ (लगइन अन्त्य गरिन्छन्, लगइन गर्न सकिँदैन); व्यक्तिगत डेटा मेटाइन्छ वा अज्ञात बनाइन्छ (नाम, इमेल, फोन, तस्बिर र क्लाइन्टको पहिचान/सम्पर्क विवरण र स्वास्थ्य क्षेत्र — रक्त समूह, एलर्जी, दीर्घकालीन अवस्था, औषधि — सफा गरिन्छन्); कानुनी रूपमा राख्नुपर्ने भुक्तानी र कमाइका अभिलेख मेटाइँदैनन्; व्यक्तिसँगको सम्बन्ध विच्छेद गरी सीमित पहुँचसहित राखिन्छन्। अनुरोधपछि फिर्ता लिने अवधि हुँदैन; पहिचान प्रमाणीकरणको अभिलेख र फाइलको स्थायी मेटाइ हालको तीस दिने पृष्ठभूमि प्रक्रियामा पूरा हुन्छ।

क्लाइन्टको अभिलेख मेटाउने र स्वास्थ्य क्षेत्र (4 अक्टोबर 2026 देखि): खाता नभएको क्लाइन्टको अभिलेख व्यवसायले मेटाउँदा अभिलेख तुरुन्तै सक्रिय सूचीबाट हटाइन्छ; 30 दिनपछि पहिचान र सम्पर्क विवरणसँगै क्लाइन्टका स्वास्थ्य क्षेत्र (रक्त समूह, एलर्जी, दीर्घकालीन अवस्था, औषधि) पनि मेटाइन्छन्/खाली गरिन्छन्। एनामनेसिस फारम, मापन र सेसन नोटका भण्डारणका नियममा यो प्रावधानले असर गर्दैन।

रसिदका फाइल (4 अक्टोबर 2026 देखि): कुनै भुक्तानीसँग नजोडिएका (अनाथ) रसिदका फाइल 7 दिनपछि स्वचालित रूपमा मेटाइन्छन्; भुक्तानीसँग जोडिएको रसिद कुनै पनि भूमिकाबाट मेटाउन सकिँदैन।

सपोर्ट मोडमा क्लाइन्टको सम्पर्क (4 अक्टोबर 2026 देखि): Corenta को सपोर्ट (सुपर-एडमिन) सत्रमा क्लाइन्टको इमेल र फोन सपोर्ट कर्मचारीलाई देखाइँदैन; सपोर्ट कर्मचारीले सीमित पहिचान सारांश (नाम, खाताको स्थिति, सक्रियता, बनाइएको मिति) मात्र देख्न सक्छन्।

स्वास्थ्य क्षेत्रमा लेख्ने अधिकार (4 अक्टोबर 2026 देखि): क्लाइन्टका स्वास्थ्य क्षेत्र (रक्त समूह, एलर्जी, दीर्घकालीन अवस्था, औषधि) मा क्लाइन्ट आफैँ र उहाँलाई तोकिएको स्पेसलिस्टले मात्र लेख्न सक्छन्; व्यवसायका मालिक/एडमिनले यी क्षेत्रमा लेख्न सक्दैनन् (आपत्कालीन सम्पर्क व्यक्ति र पहिचानका क्षेत्र सम्पादन गर्न सक्छन्)।

छद्मनामयुक्त उत्पादन मापन: उत्पादन सुधार गर्न सर्भर-पक्षमा मात्र, क्लिनिकको छद्म पहिचानसहित सामूहिक प्रयोगका घटना मापन गर्न सकिन्छ; यो मापनमा IP ठेगाना, स्वास्थ्य डेटा वा स्रोत/विज्ञापन ट्र्याकिङ हुँदैन। क्लिनिकको छद्म पहिचान छद्मनामको प्रकृतिको हो (पहिचानरहित होइन)। सुविधा हाल बन्द छ।

5.1. चरण 1 — तत्काल सफ्ट-डिलिट (Soft-Delete)

प्रयोगकर्ताले एपभित्रबाट खाता मेटाउने अनुरोध पुष्टि गर्नेबित्तिकै प्रणालीले तलका कार्य एकैसाथ र तुरुन्तै गर्छ:

  1. प्रयोगकर्ताको प्रोफाइल अभिलेखमा deleted_at क्षेत्र भरेर निष्क्रिय बनाइन्छ; खाता अब सामान्य प्रयोगका लागि पहुँचयोग्य/देखिने रहँदैन र लगइनका लागि प्रयोग गर्न सकिँदैन।
  2. प्रयोगकर्ताका बाँकी (अझै नभएका) अपोइन्टमेन्ट स्वचालित रूपमा रद्द गरिन्छन्।
  3. प्रयोगकर्ता स्पेसलिस्ट/स्रोतका रूपमा रहेका तोकाइ (क्लाइन्ट-स्पेसलिस्ट जोडी, कार्यक्रमको तोकाइ) हटाइन्छन्।
  4. प्रयोगकर्ताका सबै सहमति फिर्ता लिइन्छन् (consent_logs अभिलेखमा revoked_at क्षेत्र भरेर प्रशोधन गरिन्छ)।

यस चरणमा डेटा भौतिक रूपमा मेटाइएको हुँदैन, तर सामान्य प्रशोधन र हेर्ने उद्देश्यका लागि पहुँचयोग्य नहुने बनाइएको हुन्छ। यो KVKK धारा 7 र नियमावलीको अर्थमा "पहुँचयोग्य नहुने बनाउने" प्रकृतिको मेटाउने प्रक्रियाको पहिलो चरण हो।

5.2. चरण 2 — स्थायी रूपमा मेटाउने (30 दिनपछि)

सफ्ट-डिलिटको 30 (तीस) दिनपछि प्रणालीमा स्वचालित रूपमा चल्ने तालिकाबद्ध कार्य (cron job) ले तलका कार्य फिर्ता ल्याउन नसकिने गरी गर्छ:

  1. प्रयोगकर्ताको पहिचान प्रमाणीकरणको अभिलेख (auth.users) स्थायी र फिर्ता ल्याउन नसकिने गरी मेटाइन्छ।
  2. प्रयोगकर्तासँग जोडिएका डेटाबेसका अभिलेख वर्गअनुसार फरक तरिकाले प्रशोधन गरिन्छन्: स्वतन्त्र व्यावसायिक/प्रमाणको मूल्य नभएका अभिलेख (जस्तै नोटिफिकेसन) स्थायी रूपमा मेटाइन्छन् (DELETE/cascade); स्वास्थ्य डेटा (anamnesis_forms, session_notes, measurements) र क्लिनिक/वित्तीय अभिलेख (payments, attendance, consent_logs) भने मेटाइँदैनन्, व्यक्तिसँगको सम्बन्ध विच्छेद गरिन्छ — व्यक्तिसँगको सम्बन्ध डेटाबेस स्तरमा विच्छेद गरिन्छ, केही स्वतन्त्र पाठका क्षेत्र सफा गरिन्छन्, अभिलेख tenant को व्यक्तिसँगको सम्बन्ध विच्छेद गरिएको अभिलेखका रूपमा सीमित पहुँचसहित रहन्छ (सेसन नोटको स्वतन्त्र पाठ परिवर्तन नगरिने भएकाले अज्ञात मानिँदैन) (हेर्नुहोस् भाग 4 क्रम 2-5, 8, 10 र भाग 6.2)।
  3. यो कार्य प्रणालीको विशेषाधिकारयुक्त (service-role ले सुरक्षित) पृष्ठभूमि प्रक्रियामा मात्र स्वचालित रूपमा सुरु हुन्छ; प्रशासनिक कर्मचारीसमेत कुनै पनि प्रयोगकर्ता वा व्यवसायका एडमिनले सामान्य उत्पादनका इन्टरफेसमार्फत यो प्रक्रिया म्यानुअल रूपमा सुरु गर्न, छिटो सुरु गर्न वा रोक्न सक्दैनन् — यो गल्ती वा दुरुपयोगबाट हुने छिटो/ढिलो मेटाइ रोक्न सचेत रूपमा गरिएको सुरक्षा डिजाइन हो। (यो सुनिश्चितताले उत्पादनका सामान्य प्रयोगकर्ता र व्यवस्थापन इन्टरफेस समेट्छ; प्रणालीको विशेषाधिकारयुक्त पूर्वाधार स्तरमा प्रत्यक्ष डेटाबेस पहुँच हुन सक्ने प्राविधिक सञ्चालन प्रक्रिया यो सुनिश्चितताको दायराबाहिर छन् र छुट्टै आन्तरिक पहुँच नियन्त्रणको अधीनमा छन्।)

30 दिनको पृष्ठभूमि प्रक्रियाको उद्देश्य (4 अक्टोबर 2026 देखि): मेटाउने अनुरोधसँगै खातामा पहुँच तुरुन्तै बन्द हुने भएकाले यो अवधिले फिर्ता लिने/पछि हट्ने अवसर दिँदैन; यो पहिचान प्रमाणीकरणको अभिलेख र फाइलको स्थायी मेटाइ पूरा गर्न र सम्भावित दुरुपयोगको समीक्षाका लागि प्रयोग हुन्छ। यो अवधि KVKK धारा 5 अन्तर्गत समानुपातिकताको सिद्धान्तअनुरूप, उचित र सीमित अवधि हो। मेटाउने अनुरोधको स्थितिबारे hello@corenta.app मा आवेदन दिन सकिन्छ।

5.3. अपवाद: कानुनी रूपमा राख्नुपर्ने दायित्व भएका डेटा

माथिको 30 दिनको स्थायी रूपमा मेटाउने प्रक्रियाले भाग 4, तालिकाको क्रम नं. 6 (सदस्यता/कारोबारको मेटा डेटा) मा उल्लिखित र टर्की व्यापारिक संहिता/कर प्रक्रिया कानून अन्तर्गत कानुनी रूपमा राख्नुपर्ने दायित्व भएका अभिलेख समेट्दैन। खाता स्थायी रूपमा मेटाइए पनि यी अभिलेख सम्बन्धित कानुनी भण्डारण अवधि नसकिउन्जेल, व्यक्तिगत डेटा प्रशोधनको उद्देश्यबाट अलग गरी, कानुनी दायित्व पूरा गर्ने उद्देश्यमा मात्र सीमित पहुँचसहित छुट्टै सुरक्षित राखिन्छन्। त्यसै गरी, लेखा परीक्षण ट्रेलका अभिलेख (audit_logs) र सहमतिका अभिलेखको प्रमाण-उद्देश्यको न्यूनतम मूल भाग पनि (हेर्नुहोस् भाग 4, क्रम 7-8) वैध हित/कानुनी प्रमाणको कारणले यो 30 दिनको अवधिबाहिर, छुट्टै र सीमित उद्देश्यले राखिँदै रहन सक्छन्। यस अपवादअन्तर्गतका अवधि प्रणालीमा स्वचालित रूपमा लागू हुने प्राविधिक संयन्त्रसँग मेल खाँदैनन् भन्ने कुरा भाग 4 टिप्पणी 2 मा स्पष्ट रूपमा उल्लेख गरिएको छ।

5.4. भण्डारण गरिएका संलग्न फाइलसम्बन्धी विशेष व्याख्या (महत्त्वपूर्ण — पारदर्शिता)

पारदर्शिताको सिद्धान्तअनुसार स्पष्ट रूपमा भनिन्छ: स्थायी रूपमा मेटाउने प्रक्रियामा डेटाबेसका अभिलेख (प्रोफाइल, अपोइन्टमेन्ट, तोकाइ, सहमति आदि) पूर्ण रूपमा मेटाइन्छन् वा (स्वास्थ्य/क्लिनिक/वित्तीय अभिलेखका लागि, हेर्नुहोस् भाग 6.2) अज्ञात बनाइन्छन्; प्रयोगकर्ताका र छुट्टै भण्डारण (Storage) क्षेत्रमा राखिएका संलग्न फाइल भने यसरी व्यवस्थापन गरिन्छन्: अवतार/प्रोफाइल तस्बिर, एनामनेसिस फारममा संलग्न कागजात/तस्बिर र भुक्तानीको रसिदको तस्बिर स्थायी रूपमा मेटाउने चरणको अंशका रूपमा स्वचालित रूपमा (best-effort) Storage बाट मेटाइन्छन् — यो प्रणालीमा हाल वास्तवमै चलिरहेको, प्रमाणित व्यवहार हो। कुनै बकेटमा मेटाउने कार्य असफल भएमा यो कुरा लग गरिन्छ; तर यसले अरू बकेटको सफाइ वा खाताका अज्ञात बनाउने/स्थायी रूपमा मेटाउने चरण रोक्दैन (best-effort डिजाइन)।

इमानदार सीमा: यो स्वचालित प्रक्रियाको दायराबाहिर रहने एकमात्र फाइलको वर्ग स्पेसलिस्ट/एकल दर्ता प्रक्रियामा अपलोड गरिएका पहिचान/डिप्लोमा प्रमाणीकरणका कागजात हुन् (specialist-verification-docs बकेट)। यी कागजात प्राविधिक रूपमा प्रयोगकर्तासँग होइन, सम्बन्धित tenant (क्लिनिक) को प्रमाणीकरण प्रक्रियासँग जोडिएका छन् र डेटाबेसको अभिलेखमा प्रयोगकर्ताको सन्दर्भ बोक्दैनन्; त्यसैले हालको प्रयोगकर्ता-खाता-मेटाउने प्रवाहमा स्वचालित रूपमा समावेश गर्न सकिएको छैन। यो कागजातको निष्कासन सम्बन्धित क्लिनिकले tenant स्तरमा आफ्नो खाता/सदस्यता बन्द गर्ने प्रक्रियामा छुट्टै गरिनेछ (हेर्नुहोस् भाग 5.6); त्यो पूरा नहुन्जेल अपवादजनक अनुरोध hello@corenta.app मार्फत म्यानुअल रूपमा मूल्याङ्कन गरिन्छन्।

त्यसैले यस नीतिमा खाता मेटाउने अनुरोधसँगै "प्रयोगकर्ताका सबै डेटा/फाइल पूर्ण र तुरुन्तै मेटाइन्छन्" भन्ने निरपेक्ष प्रतिबद्धता गरिएको छैन (विशेष गरी ब्याकअपका प्राविधिक अवशेषका लागि हेर्नुहोस् भाग 6.3, र माथिको अपवाद); तर माथि वर्णन गरिएका फाइलका वर्गका सम्बन्धमा स्वचालित मेटाइ वास्तवमै लागू भइरहेको छ।

5.5. स्वास्थ्य डेटासम्बन्धी विशेष टिप्पणी

एनामनेसिस फारम, सेसन नोट र मापनका अभिलेखजस्ता विशेष प्रकृतिका स्वास्थ्य डेटा पनि माथिको सामान्य मेटाउने प्रवाह (सफ्ट-डिलिट → 30 दिन → स्थायी रूपमा मेटाउने) को अधीनमा छन्; तर भाग 4 क्रम 2-4 र भाग 6.2 मा व्याख्या गरिएझैँ यी तालिकामा स्थायी रूपमा मेटाउने चरण व्यक्तिसँगको सम्बन्ध विच्छेद र आंशिक सफाइ मार्फत लागू गरिन्छ — अभिलेखलाई DELETE गरिँदैन, व्यक्तिसँगको सम्बन्ध विच्छेद गरिन्छ र केही स्वतन्त्र पाठका क्षेत्र सफा गरिन्छन्; क्लिनिकल अभिलेख (विशेष गरी append-only सेसन नोटको सामग्री) tenant को व्यक्तिसँगको सम्बन्ध विच्छेद गरिएको अभिलेखका रूपमा सीमित पहुँचसहित राखिन्छ र अज्ञात मानिँदैन। साथै, यो डेटाको वर्ग क्लिनिकले डेटा नियन्त्रकका रूपमा राख्ने अभिलेखसँग गाँसिएको हुनाले, क्लाइन्टको खाता/डेटा मेटाउने अनुरोध क्लिनिकका आफ्नै कानुनी भण्डारण दायित्व (उदाहरणका लागि स्वास्थ्य सेवा प्रदानसम्बन्धी कानूनबाट आउन सक्ने अभिलेख राख्ने बाध्यता) सँग बाझिन सक्छ; व्यक्तिसँगको सम्बन्ध विच्छेद र सीमित भण्डारणको विधिले यी दुई दायित्व (व्यक्तिगत डेटामाथि क्लाइन्टका अधिकार र क्लिनिकको अभिलेख राख्ने दायित्व) बीच सन्तुलन राख्ने लक्ष्य राख्छ। यस्ता अवस्थामा अन्तिम निर्णय गर्ने निकाय डेटा नियन्त्रकका रूपमा क्लिनिक हो; Corenta ले क्लिनिकको निर्देशनअनुसार काम गर्छ।

5.6. क्लिनिक (Tenant) स्तरमा मेटाउने

कुनै क्लिनिकले आफ्नो Corenta सदस्यता पूर्ण रूपमा अन्त्य गरेमा, क्लिनिकको tenant डेटा र यो tenant अन्तर्गतका सबै क्लाइन्ट अभिलेखका लागि पनि उही दुई चरणको (सफ्ट-डिलिट → 30 दिन → स्थायी रूपमा मेटाउने) संरचना लागू हुन्छ। क्लिनिक आफ्ना क्लाइन्टको डेटा नियन्त्रक भएकाले, सदस्यता अन्त्य गर्नुअघि आफ्नै KVKK दायित्वको ढाँचाभित्र क्लाइन्टलाई जानकारी दिन बाध्य छ; यो दायित्व Corenta लाई हस्तान्तरण गर्न सकिँदैन।

5.7. सुपर-एडमिन सपोर्ट मोड (Impersonation) सँगको सम्बन्ध

खाता मेटाउने र भण्डारणका प्रक्रिया Corenta को सपोर्ट/impersonation संयन्त्रबाट स्वतन्त्र रूपमा चल्छन्। impersonation सत्र समय-सीमित (30 मिनेट) हुन्छन् र पूर्वनिर्धारित रूपमा पढ्न-मात्र हुन्छन्; स्वास्थ्य डेटाका वर्ग (एनामनेसिस, सेसन नोट, मापन) मा पहुँचका लागि छुट्टै स्वीकृतिको चरण (health_data_enabled) आवश्यक हुन्छ र यी तालिकामा लेख्ने/मेटाउने कार्यलाई impersonation मार्फत कुनै पनि हालतमा अनुमति दिइँदैन (RLS नीतिमा impersonation लाई कुनै अपवाद दिइएको छैन)। स्पष्टीकरण: यहाँको सीमा सपोर्ट कर्मचारीले सत्र खोलेर म्यानुअल रूपमा काम गर्ने मानवद्वारा सुरु गरिएका impersonation सत्रसम्बन्धी हो; भाग 5.2 मा व्याख्या गरिएको स्वचालित (मानव हस्तक्षेपबिनाको) service-role cron प्रक्रिया यो सीमाबाट अलग तह हो र यसबाट प्रभावित हुँदैन — impersonation को सीमाले खाता मेटाउने प्रवाहको स्वचालित स्थायी मेटाउने संयन्त्र रोक्दैन वा त्यससँग मिसाउनु हुँदैन। त्यसैले खाता मेटाउने/निष्कासनका प्रक्रिया यस नीतिमा परिभाषित स्वचालित संयन्त्रमार्फत मात्र सञ्चालन हुन्छन्।

6. निष्कासनका विधि

नियमावलीको धारा 8 र त्यसपछिका प्रावधानअनुसार, अभिलेख माध्यमअनुसार लागू हुने मेटाउने/नष्ट गर्ने/अज्ञात बनाउने विधि तल व्याख्या गरिएका छन्।

6.1. मेटाउने

व्यक्तिगत डेटालाई सम्बन्धित प्रयोगकर्ताका लागि (एपका प्रयोगकर्ता, एडमिन प्यानलमा पहुँच भएका कर्मचारीसमेत) कुनै पनि हालतमा पहुँचयोग्य र पुनः प्रयोगयोग्य नहुने बनाउने प्रक्रिया हो। Corenta मा यो विधि चरण-1 को सफ्ट-डिलिट प्रक्रियामा लागू हुन्छ: डेटा भौतिक रूपमा डेटाबेसबाट नहटाइए पनि पहुँचका अधिकार र इन्टरफेसमार्फत पूर्ण रूपमा पहुँचयोग्य नहुने बनाइन्छ।

6.2. नष्ट गर्ने (स्थायी रूपमा मेटाउने)

व्यक्तिगत डेटालाई कसैले पनि कुनै पनि हालतमा पहुँच गर्न, फिर्ता ल्याउन र पुनः प्रयोग गर्न नसक्ने बनाउने प्रक्रिया हो। Corenta को चरण-2 स्थायी रूपमा मेटाउने प्रक्रियामा यो सिद्धान्त डेटाको वर्गअनुसार दुई फरक प्राविधिक विधिबाट कार्यान्वयन गरिन्छ:

  • पहिचान प्रमाणीकरणको अभिलेख र स्वतन्त्र व्यावसायिक मूल्य नभएका अभिलेख: प्रयोगकर्ताको पहिचान प्रमाणीकरणको अभिलेख (auth.users) service-role ले सुरक्षित स्वचालित प्रक्रियामा प्रत्यक्ष DELETE बाट फिर्ता ल्याउन नसकिने गरी मेटाइन्छ; खाता मेटाएपछि आफैँमा कुनै व्यावसायिक/प्रमाणको मूल्य नभएका सम्बन्धित अभिलेख (जस्तै नोटिफिकेसन, notifications — हेर्नुहोस् भाग 4 क्रम 10) डेटाबेस स्तरमा ON DELETE CASCADE बाट सँगै मेटाइन्छन्।
  • स्वास्थ्य, क्लिनिक र वित्तीय अभिलेख: anamnesis_forms, session_notes, measurements, payments, attendance र consent_logs का लागि स्थायी रूपमा मेटाउने चरण अभिलेखलाई DELETE गर्नुको सट्टा व्यक्तिसँगको सम्बन्ध विच्छेद र आंशिक सफाइ (हेर्नुहोस् भाग 6.6) मार्फत लागू गरिन्छ: व्यक्तिलाई पहिचान गराउने फरेन की कोलम (client_id, specialist_id, user_id आदि) लाई ON DELETE SET NULL FK सीमाबाट फिर्ता ल्याउन नसकिने गरी NULL बनाइन्छ; स्पष्ट पहिचान वा स्वतन्त्र पाठको PII हुन सक्ने सामग्रीका कोलम (एनामनेसिसका उत्तर, मापन/भुक्तानीका स्वतन्त्र पाठका नोट, भुक्तानीको रसिदको सन्दर्भ, सहमतिको अभिलेखको IP ठेगाना) लाई anonymize_user_relations() फङ्सनले (service-role ले मात्र बोलाउन सकिने, default-deny) सफा गर्छ वा अज्ञात चिन्हले बदल्छ। क्लिनिक/वित्तीय सङ्ख्यात्मक र ऐतिहासिक सामग्री (मिति, रकम, मापनको मान, बाँकी सेसनको सङ्ख्या, आयो/आएन भन्ने स्थिति, सहमति दिइएको/फिर्ता लिइएको समय) भने क्लिनिकको अभिलेख राख्ने दायित्व र (सेसन नोटका लागि) append-only सिद्धान्तअनुसार tenant को व्यक्तिसँगको सम्बन्ध विच्छेद गरिएको अभिलेखका रूपमा राखिँदै रहन्छ; सेसन नोटको स्वतन्त्र पाठ परिवर्तन नगरिने भएकाले यी अभिलेख अज्ञात मानिँदैनन् र सीमित पहुँचसहित राखिन्छन्।

सेसन नोट (session_notes) मा append-only सीमाले सामग्री परिवर्तन गर्न दिँदैन; व्यक्तिसँगका सम्बन्धका कोलम (client_id, specialist_id) लाई NULL बनाउन मात्र साँघुरो, एउटै उद्देश्यको अपवाद दिइएको छ — नोटको सामग्री आफैँ यो प्रक्रियामा पनि कुनै पनि चरणमा मेटाइँदैन वा परिवर्तन गरिँदैन।

सीमा: स्वतन्त्र पाठका क्षेत्रमा स्पष्ट पहिचानका कोलमबाहेक आउन सक्ने पाठभित्रको व्यक्तिगत डेटा (जस्तै सेसन नोटको मुख्य भागमा आएको नाम) का लागि स्क्यानिङ/सफाइ संयन्त्र छैन। त्यसैले यी अभिलेख अज्ञात मानिँदैनन्; व्यक्तिगत डेटाका रूपमा सीमित पहुँचसहित राखिन्छन् र अवधि सकिएपछि निष्कासन गरिन्छन्।

माथिका दुवै विधि service-role ले सुरक्षित भएकाले सामान्य उत्पादनका इन्टरफेसमार्फत सुरु गर्न वा फिर्ता लिन सकिँदैन।

6.3. ब्याकअपबाट मेटाउने

डेटाबेसका ब्याकअप सामान्य ब्याकअप चक्र (रोटेसन) को ढाँचाभित्र निश्चित अवधिपछि स्वचालित रूपमा अधिलेखन/निष्कासन गरिन्छन्। स्थायी रूपमा मेटाउने प्रक्रिया मुख्य डेटाबेसमा तुरुन्तै प्रभावकारी भए पनि, पहिले लिइएका ब्याकअपमा डेटा ब्याकअप प्रदायक (Supabase) को मानक ब्याकअप रोटेसन अवधि नसकिउन्जेल प्राविधिक रूपमा रहिरहन सक्छ भन्ने कुरा स्पष्ट रूपमा उल्लेख गरिन्छ। यो सम्बन्धित उप-प्रशोधक (Supabase) को डेटा प्रशोधन सम्झौता (DPA) अन्तर्गतको मानक अभ्यास हो।

6.4. फाइल भण्डारण (Storage) क्षेत्रका संलग्नक

प्रयोगकर्ताले अपलोड गरेका अवतारका तस्बिर, भुक्तानीका रसिद र एनामनेसिसका संलग्नकजस्ता फाइल छुट्टै भण्डारण (Storage) क्षेत्रमा राखिन्छन्। हेर्नुहोस् भाग 5.4 — यी सामग्रीको खाता मेटाउने प्रक्रियामा हालको अवस्था (अवतार/एनामनेसिसको संलग्नक/भुक्तानीको रसिदका लागि स्वचालित मेटाइ, specialist-verification-docs का लागि एकमात्र अपवाद) त्यहाँ विस्तृत र पारदर्शी रूपमा व्याख्या गरिएको छ।

6.5. कागजी माध्यमका डेटा

Corenta को SaaS उत्पादन अन्तर्गत प्रशोधन गरिने व्यक्तिगत डेटा डिजिटल माध्यममा राखिन्छन्; कागजी माध्यममा व्यक्तिगत डेटा प्रशोधन गर्ने परिकल्पना गरिएको छैन। कम्पनीका व्यावसायिक/प्रशासनिक पत्राचारमा अपवादस्वरूप कागजी माध्यम प्रयोग भएमा, निष्कासन कालो पोत्ने/जलाउने/कागज टुक्र्याउने मेसिनबाट फिर्ता ल्याउन नसकिने गरी टुक्र्याउने विधिबाट गरिन्छ।

6.6. अज्ञात बनाउने

Corenta ले खाता स्थायी रूपमा मेटाउने प्रक्रियाको अंशका रूपमा (हेर्नुहोस् भाग 6.2) स्वास्थ्य डेटा र क्लिनिक/वित्तीय अभिलेखका लागि व्यक्तिसँगको सम्बन्ध विच्छेद र आंशिक सफाइको विधि प्रयोग गर्छ। सेसन नोटको स्वतन्त्र पाठ परिवर्तन नगरिने र साना व्यवसायमा मिति र मापनको शृङ्खलाले व्यक्तिलाई फेरि पहिचान गर्न पुग्न सक्ने भएकाले, यो विधिले तलको अज्ञात बनाउने मापदण्ड हरेक अवस्थामा पूरा गर्दैन; यी अभिलेख अज्ञात मानिँदैनन्, व्यक्तिगत डेटाका रूपमा सीमित पहुँचसहित राखिन्छन् र अवधि सकिएपछि निष्कासन गरिन्छन्। यसबाहेक Corenta ले उत्पादन विकास, तथ्याङ्कीय विश्लेषण वा बजार अनुसन्धानका उद्देश्यले पनि पहिचान भएको वा पहिचान गर्न सकिने प्राकृतिक व्यक्तिसँग जोड्न सम्भव नहुने गरी अज्ञात बनाइएका डेटा प्रयोग गर्न सक्छ। अज्ञात बनाउने प्रक्रियाले डेटालाई अन्य डेटासँग मिलाए पनि फिर्ता ल्याउन नसकिने गरी व्यक्तिसँग जोड्न नसकिने बनाउन आवश्यक हुन्छ; यो मापदण्ड पूरा नगरी गरिएको मास्किङ/छद्मनामीकरणलाई अज्ञात बनाउने मानिँदैन र त्यो व्यक्तिगत डेटा प्रशोधनको व्यवस्थाको अधीनमा रहिरहन्छ। अज्ञात बनाइएका डेटा KVKK को दायराबाहिर मानिन्छन् र यस नीतिका भण्डारण अवधिका सीमाको अधीनमा हुँदैनन्।

6.7. विधिको छनोट

लागू हुने निष्कासनको विधि डेटाको प्रकृति (विशेष प्रकृतिको हो वा होइन), राखिएको माध्यम (डेटाबेस, फाइल भण्डारण, लग प्रणाली, ब्याकअप प्रणाली), कानुनी र प्राविधिक सम्भावना तथा बोर्डका निर्णय र नियमावलीमा उल्लिखित सिद्धान्तलाई ध्यानमा राखेर Corenta र/वा क्लिनिकले निर्धारण गर्छ। विशेष प्रकृतिका व्यक्तिगत डेटा (स्वास्थ्य डेटासमेत) को निष्कासनमा अधिकतम सावधानी अपनाइन्छ।

7. आवधिक निष्कासनको प्रक्रिया

नियमावलीको धारा 11 बमोजिम, Corenta भण्डारण अवधि सकिएका र/वा प्रशोधनको उद्देश्य नरहेका व्यक्तिगत डेटा आफैँ (अनुरोध नपर्खी) मेटाउने, नष्ट गर्ने वा अज्ञात बनाउने दायित्वमा छ; यस अन्तर्गत तोकिने आवधिक निष्कासनको अवधि 6 (छ) महिनाभन्दा बढी हुन सक्दैन। यस ढाँचाभित्र प्रणालीमा हाल वास्तवमै चलिरहेका र नचलिरहेका संयन्त्रबीच तलको भिन्नता स्पष्ट रूपमा देखाइन्छ:

  1. खाता मेटाउने अनुरोधपछिको 30 दिनको स्थायी रूपमा मेटाउने प्रक्रिया स्वचालित तालिकाबद्ध कार्य (cron job) ले आवधिक रूपमा (दैनिक) स्क्यान गर्छ र अवधि सकिएका खाता एकमुष्ट प्रशोधनमा लिइन्छन्। यो प्रणालीमा हाल वास्तवमै चलिरहेको, प्रमाणित स्वचालन हो।
  2. लेखा परीक्षण ट्रेलका अभिलेख (audit_logs) का लागि तोकिएको भण्डारण अवधि आवधिक रूपमा समीक्षा गरिन्छ; तर यो समीक्षा स्वचालित रूपमा कार्यान्वयन गर्ने मेटाउने संयन्त्र हाल लागू गरिएको छैन (हेर्नुहोस् भाग 4, क्रम 7)।
  3. अर्ली एक्सेस फारमका डेटाका लागि तोकिएको अधिकतम भण्डारण अवधि (हेर्नुहोस् भाग 4, क्रम 9) नियमावलीको धारा 11 अन्तर्गतको आवधिक निष्कासन दायित्वको कानुनी माथिल्लो सीमाको सन्दर्भ हो; तर यो अवधिसँग मेल खाने, प्रणालीमा स्वचालित रूपमा चल्ने स्क्यानिङ/मेटाउने संयन्त्र हाल छैन। यो डेटाको वर्गका लागि मेटाउने/अज्ञात बनाउने प्रक्रिया स्वचालन लागू नहुन्जेल म्यानुअल रूपमा र अनुरोधमा मूल्याङ्कन गरिन्छ (हेर्नुहोस् भाग 4, टिप्पणी 2)। यो कुरा अन्य अप्रमाणित स्वचालनका दाबी (हेर्नुहोस् बुँदा 2 र 4) सँग सुसङ्गत रूपमा पारदर्शी राखिन्छ।
  4. म्याद सकिएका/अमान्य पुस नोटिफिकेसन टोकनलाई छुट्टै स्वचालित र आवधिक रूपमा सफा गर्ने कुरा उत्पादनको रोडम्यापमा योजना गरिएको सुधार हो; यो संयन्त्र प्रणालीमा हाल वास्तवमै चलिरहेको छ भन्ने कुरा प्राविधिक रूपमा प्रमाणित भएको छैन (हेर्नुहोस् भाग 4, क्रम 10)। प्रमाणित भएमा वा लागू भएमा यो नीति अद्यावधिक गरिनेछ।
  5. 6 महिनाको आवधिक निष्कासन: यस भागमा स्वचालित निष्कासन नभएका वर्ग (लेखा परीक्षण ट्रेल, व्यक्तिसँगको सम्बन्ध विच्छेद गरिएका अनुमतिका प्रमाण, अर्ली एक्सेस फारमका डेटा, स्पेसलिस्ट प्रमाणीकरणका कागजात, समूहको सन्देशको मोडरेसन प्रतिलिपि) का लागि Corenta ले 6 महिनामा एक पटक आवधिक निष्कासन लागू गर्छ र प्रत्येक चक्रका लागि निष्कासनको मुचुल्का तयार गर्छ। यी चक्र स्वचालित गर्ने तालिकाबद्ध कार्य अझै छैनन्; चक्र म्यानुअल रूपमा सञ्चालन गरिन्छन्।

आवधिक निष्कासनको प्रक्रियाले, यस नीतिमा उल्लिखित अवधिबाट स्वतन्त्र रूपमा, KVKK धारा 11 अन्तर्गत डेटा धनीले गर्ने व्यक्तिगत मेटाउने/नष्ट गर्ने अनुरोध रोक्दैन; भण्डारण अवधि नसकिए पनि सम्बन्धित प्रशोधन गतिविधिको कानुनी आधार नरहेमा (जस्तै सहमति फिर्ता लिएमा) डेटा धनीले मेटाउन अनुरोध गर्न सक्छ। स्वचालन अझै लागू नभएका वर्गका सम्बन्धमा पनि डेटा धनीको व्यक्तिगत अनुरोध hello@corenta.app मार्फत पठाइएमा म्यानुअल रूपमा मूल्याङ्कन गरी टुङ्ग्याइन्छ।

8. डेटा धनीका अधिकार र आवेदनको प्रक्रिया (KVKK धारा 11)

8.1. KVKK धारा 11 अन्तर्गतका अधिकार

KVKK धारा 11 बमोजिम डेटा धनीसँग तलका अधिकार छन्:

  1. आफ्नो व्यक्तिगत डेटा प्रशोधन गरिएको छ वा छैन भनी थाहा पाउने,
  2. व्यक्तिगत डेटा प्रशोधन गरिएको भए त्यससम्बन्धी जानकारी माग्ने,
  3. व्यक्तिगत डेटा प्रशोधनको उद्देश्य र ती उद्देश्यअनुरूप प्रयोग भए/नभएको थाहा पाउने,
  4. देशभित्र वा विदेशमा व्यक्तिगत डेटा स्थानान्तरण गरिएका तेस्रो पक्ष थाहा पाउने,
  5. व्यक्तिगत डेटा अपूर्ण वा गलत रूपमा प्रशोधन भएको भए सच्याउन माग्ने,
  6. KVKK धारा 7 को ढाँचाभित्र व्यक्तिगत डेटा मेटाउन वा नष्ट गर्न माग्ने,
  7. माथिका (5) र (6) खण्डबमोजिम गरिएका कार्यबारे व्यक्तिगत डेटा स्थानान्तरण गरिएका तेस्रो पक्षलाई सूचित गर्न माग्ने,
  8. प्रशोधन गरिएका डेटा विशेष रूपमा स्वचालित प्रणालीमार्फत विश्लेषण गरिँदा व्यक्तिको विरुद्धमा कुनै परिणाम निस्किएमा त्यसमा आपत्ति जनाउने,
  9. व्यक्तिगत डेटा कानूनविपरीत प्रशोधन गरिएका कारण क्षति भएमा क्षतिपूर्ति माग्ने।

8.2. हालको प्राविधिक कार्यान्वयनको इमानदार सारांश

तलका कुरा हालको प्राविधिक कार्यान्वयनको इमानदार र यथार्थपरक सारांशका रूपमा प्रस्तुत गरिन्छन्:

  • मेटाउने अनुरोध (खाता मेटाउने): मोबाइल एपभित्रको सम्बन्धित सेटिङ मेनुबाट प्रत्यक्ष अनुरोध गर्न सकिन्छ; यो अनुरोध भाग 5 मा व्याख्या गरिएको दुई चरणको (तत्काल सफ्ट-डिलिट → 30 दिन → स्थायी रूपमा मेटाउने) प्रक्रियाबाट स्वचालित रूपमा पूरा गरिन्छ (धारा 11/6)।
  • जानकारीको अनुरोध / डेटाको पोर्टेबिलिटी: डेटा धनीको आफ्नै tenant को दायराभित्रका डेटा संरचित, मेसिनले पढ्न सकिने ढाँचामा, उचित अवधिभित्र उहाँलाई उपलब्ध गराएर पूरा गरिन्छ (export_user_data फङ्सन, tenant-scope प्रमाणित)। यो प्रक्रियाको हस्तान्तरण संयन्त्र (फाइलको ढाँचा, हस्तान्तरणको तरिका, हस्ताक्षरित डाउनलोड लिङ्कजस्ता विशेषता) निरन्तर विकास गरिँदै छ; यस नीतिअन्तर्गत कुनै निश्चित हस्तान्तरण अवधि वा विशिष्ट फाइल/पहुँचको ढाँचाबारे प्रतिबद्धता गरिएको छैन (धारा 11/1-2)।
  • तेस्रो पक्षलाई स्थानान्तरणको जानकारी (धारा 11/4): व्यक्तिगत डेटा स्थानान्तरण गरिएका देशभित्र/विदेशका तेस्रो पक्ष/उप-प्रशोधकबारेको जानकारी यस नीतिको भाग 11 (उप-प्रशोधक र डेटाको स्थानीयकरण) को तालिकाले पूरा गर्छ।
  • सच्याउने अनुरोध (धारा 11/5): प्राविधिक रूपमा क्लिनिकको व्यवस्थापन प्यानलबाट म्यानुअल रूपमा गर्न सकिन्छ; छुट्टै, स्वचालित "सच्याउने अनुरोध" कार्यप्रवाह छैन। SaaS उत्पादनको सन्दर्भमा क्लाइन्टको डेटासम्बन्धी सच्याउने अनुरोध पहिले सम्बन्धित क्लिनिकमा पठाउनुपर्छ; Corenta ले डेटा प्रशोधकका रूपमा क्लिनिकको निर्देशनअनुसार प्राविधिक सहयोग दिन्छ।
  • तेस्रो पक्षलाई सूचना (धारा 11/7): मेटाउने/सच्याउने कार्य स्थानान्तरण गरिएका तेस्रो पक्षलाई सूचित गर्ने अनुरोध आवेदनको प्रक्रियामा उल्लिखित माध्यमबाट पठाइएमा मूल्याङ्कन गरिन्छ; यो प्रक्रिया हाल स्वचालित होइन, म्यानुअल रूपमा सञ्चालन गरिन्छ।
  • स्वचालित निर्णय/प्रोफाइलिङमा आपत्ति (धारा 11/8): प्रणालीमा प्रशोधन गरिएका डेटा विशेष रूपमा स्वचालित प्रणालीमार्फत विश्लेषण गरी डेटा धनीको विरुद्धमा परिणाम निकाल्ने स्वचालित निर्णय वा प्रोफाइलिङ गतिविधि छैन; त्यसैले यस बुँदासम्बन्धी वास्तवमै सञ्चालन हुने छुट्टै आपत्ति संयन्त्रको आवश्यकता हाल परेको छैन।
  • आवेदन KVKK धारा 13 बमोजिम बढीमा 30 दिनभित्र निःशुल्क टुङ्ग्याइन्छन् (प्रक्रियामा छुट्टै लागत लागेमा बोर्डले तोकेको दररेटअनुसारको शुल्क माग्न सकिन्छ)।

8.3. आवेदनको प्रक्रिया

माथिका अधिकारसम्बन्धी अनुरोध:

  • hello@corenta.app इमेल ठेगानामा,
  • एपभित्रका सम्बन्धित सेटिङ/सपोर्ट स्क्रिनमार्फत,
  • वा KVKK ले तोकेका अन्य तरिकाबाट,

Corenta लाई पठाउन सकिन्छ।

क्लाइन्टको डेटासम्बन्धी महत्त्वपूर्ण टिप्पणी: तपाईं कुनै क्लिनिकको क्लाइन्ट हुनुहुन्छ र आफ्नो डेटाबारे अनुरोध गर्न चाहनुहुन्छ भने, पहिले सम्बन्धित क्लिनिक (डेटा नियन्त्रक) मा आवेदन दिनुपर्छ; किनकि क्लाइन्टको डेटाका सम्बन्धमा अन्तिम निर्णय गर्ने निकाय र सम्बोधन गर्नुपर्ने पक्ष क्लिनिक हो। Corenta ले डेटा प्रशोधकका रूपमा क्लिनिकको निर्देशनअनुसार आवश्यक प्राविधिक औजार (डेटा हेर्ने, निर्यात गर्ने, मेटाउने फङ्सन) उपलब्ध गराउँछ।

9. भूमिका र जिम्मेवारी

भूमिकाजिम्मेवारी
Corenta / [Teta Studio]कर्पोरेट वेबसाइटको सन्दर्भमा डेटा नियन्त्रकका रूपमा यो नीति लागू गर्ने; SaaS उत्पादनको सन्दर्भमा भने डेटा प्रशोधकका रूपमा, क्लिनिकको निर्देशनअनुसार प्राविधिक भण्डारण/निष्कासनको पूर्वाधार (सफ्ट-डिलिट, cron मा आधारित स्थायी मेटाइ, RLS पहुँच सीमा) उपलब्ध गराउने जिम्मेवारी।
क्लिनिक (Tenant/व्यवसाय)SaaS उत्पादनको सन्दर्भमा आफ्ना क्लाइन्टका व्यक्तिगत डेटाका सम्बन्धमा डेटा नियन्त्रकका रूपमा, क्लाइन्टप्रति सूचना दिने दायित्व, स्पष्ट सहमति लिने कार्य र आफ्नै आन्तरिक भण्डारण/निष्कासनका निर्णय (जस्तै कुन क्लाइन्टको अभिलेख कहिले मेटाउने) को जिम्मेवारी।
प्रणाली / स्वचालित प्रक्रियातालिकाबद्ध कार्य (cron) मार्फत आवधिक निष्कासन र 30 दिनको स्थायी मेटाउने प्रक्रिया प्राविधिक रूपमा कार्यान्वयन गर्ने जिम्मेवारी; यी प्रक्रिया विशेषाधिकारयुक्त (service-role) अधिकारबाट मात्र सुरु गर्न सकिन्छ।
सपोर्ट/ग्राहक सम्बन्ध टिमसम्बन्धित व्यक्तिका आवेदन लिने, पठाउने र प्रक्रियाको अनुगमन गर्ने जिम्मेवारी।
डेटा नियन्त्रकको सम्पर्क व्यक्तिKVKK आवेदन कानूनअनुरूप टुङ्ग्याउने, आवश्यक परेमा व्यक्तिगत डेटा संरक्षण प्राधिकरणसँग सम्पर्क गर्ने जिम्मेवारी।

10. सुरक्षाका उपाय (भण्डारण अवधिभर)

भण्डारण अवधिभर व्यक्तिगत डेटा तलका प्राविधिक र प्रशासनिक उपायबाट सुरक्षित राखिन्छन् (KVKK धारा 12):

  • बहु-भाडावाल (multi-tenant) संरचनामा प्रत्येक तालिकामा tenant_id अनिवार्य र Row Level Security नीतिमार्फत पूर्वनिर्धारित-अस्वीकार (default-deny) सिद्धान्त लागू गरिन्छ (37/37 तालिका, 86 नीति); यसरी भाडावालबीच डेटा चुहावट प्राविधिक रूपमा रोकिन्छ।
  • स्वास्थ्य डेटा भएका तालिकामा पहुँच सम्बन्धित क्लाइन्ट, तोकिएको स्पेसलिस्ट र tenant एडमिनमा मात्र सीमित छ; पहुँच नियन्त्रण डेटाबेस स्तरमा (RLS) लागू गरिन्छ। सेसन नोट पठाएपछि परिवर्तन गर्न/मेटाउन सकिँदैन (append-only); एनामनेसिस फारमका लागि कुनै पनि प्रयोगकर्तालाई (एडमिनसमेत) मेटाउने अधिकार दिइएको छैन।
  • सुपर-एडमिन सपोर्ट मोड (impersonation) समय-सीमित (30 मिनेट) र पूर्वनिर्धारित रूपमा पढ्न-मात्र हुन्छ; लेख्ने कार्य र स्वास्थ्य डेटामा पहुँच छुट्टै, थप स्वीकृति चाहिने चरणको अधीनमा छन्; कुनै पनि impersonation अवस्थामा स्वास्थ्य डेटाका तालिकामा लेख्ने पहुँच खोलिँदैन। (यो सीमा मानवद्वारा सुरु गरिएका impersonation सत्रसम्बन्धी हो; स्वचालित service-role cron प्रक्रिया छुट्टै तह हो — हेर्नुहोस् भाग 5.7।)
  • डेटा स्थानान्तरणमा एन्ड-टु-एन्ड इन्क्रिप्सन (TLS) प्रयोग गरिन्छ; मोबाइल एपमा सत्र टोकन डिभाइसको सुरक्षित हार्डवेयर-समर्थित कुञ्जी भण्डार (Keychain/Keystore) मा इन्क्रिप्ट गरी राखिन्छन्।
  • संवेदनशील स्क्रिनमा स्क्रिनसट लिन सीमित गर्ने प्राविधिक उपाय अपनाइएका छन्।
  • सुपर-एडमिन खाताका लागि दुई-चरणको पहिचान प्रमाणीकरण (2FA/MFA) अनिवार्य छ।
  • भुक्तानीसम्बन्धी सूचना (webhook) को क्रिप्टोग्राफिक हस्ताक्षर प्रमाणीकरण संरचनामा परिकल्पना गरिएको छ र लागू भइरहेको छ; सम्बन्धित कन्फिगरेसन/कुञ्जी व्यवस्थापन सबै वातावरणमा (prod समेत) पूर्ण रूपमा सम्पन्न गर्ने काम जारी छ।
  • यी सुरक्षाका उपाय निरन्तर समीक्षा र सुधार गरिन्छन्; तर कुनै पनि प्राविधिक उपायले पूर्ण सुरक्षाको ग्यारेन्टी दिँदैन र यस नीतिअन्तर्गत पूर्ण सुरक्षाको प्रतिबद्धता दिइएको छैन।

11. उप-प्रशोधक र डेटाको स्थानीयकरण

भण्डारण अवधिभर व्यक्तिगत डेटा तलका उप-प्रशोधक/सेवा प्रदायकमार्फत प्रशोधन वा होस्ट गरिन्छन्। यी प्रदायकसँगका सम्झौतामा डेटा तोकिएको सेवा कार्यान्वयन गर्ने उद्देश्यले मात्र प्रशोधन गर्ने दायित्व तोकिएका छन्; यो सम्बन्धले भण्डारण अवधि होइन, डेटा होस्ट गरिएको प्राविधिक वातावरण जनाउँछ — निष्कासनको निर्णय यी प्रदायकमा पनि प्राविधिक रूपमा कार्यान्वयन गरिन्छ। तलको तालिकाले KVKK धारा 11/4 अन्तर्गत "डेटा स्थानान्तरण गरिएका तेस्रो पक्ष थाहा पाउने" अधिकार पनि पूरा गर्छ:

उप-प्रशोधकभूमिकाडेटाको स्थानविदेश स्थानान्तरण (KVKK धारा 9)
Supabaseडेटाबेस, पहिचान प्रमाणीकरण, फाइल भण्डारण, सर्भर-पक्षीय फङ्सन होस्टिङFrankfurt, जर्मनीविदेश स्थानान्तरण हो; KVKK धारा 9/4-c को मानक सम्झौता (मोड्युल 3): अझै हस्ताक्षर भएको छैन र बोर्डलाई सूचित गरिएको छैन
AppleApp Store वितरण, एपभित्रको खरिद (IAP) बिलिङ, पुस नोटिफिकेसन (APNs)विश्वव्यापी पूर्वाधारविदेश स्थानान्तरण हो; KVKK मानक सम्झौता: अझै हस्ताक्षर भएको छैन
GooglePlay Store वितरण, एपभित्रको खरिद (IAP) बिलिङ, पुस नोटिफिकेसन (FCM)विश्वव्यापी पूर्वाधारविदेश स्थानान्तरण हो; KVKK मानक सम्झौता: अझै हस्ताक्षर भएको छैन
Vercelवेब (व्यवस्थापन प्यानल / Next.js) होस्टिङविश्वव्यापी पूर्वाधारविदेश स्थानान्तरण हो; KVKK मानक सम्झौता: अझै हस्ताक्षर भएको छैन
Framercorenta.app कर्पोरेट/मार्केटिङ साइटको होस्टिङविश्वव्यापी पूर्वाधारविदेश स्थानान्तरण हो; KVKK मानक सम्झौता (मोड्युल 2): अझै हस्ताक्षर भएको छैन
Google Workspace (Google)सेवा इमेल (ट्रायल, निमन्त्रणा, सपोर्ट) पठाउने र सपोर्ट/सम्पर्कका इनबक्सविश्वव्यापी पूर्वाधारविदेश स्थानान्तरण हो; KVKK मानक सम्झौता: अझै हस्ताक्षर भएको छैन

थप रूपमा:

  • इमेलको पूर्वाधार: सेवा इमेल Google Workspace (Google) मार्फत पठाइन्छन्; पहिचान प्रमाणीकरणका इमेल Supabase Auth ले सुरु गर्छ। प्रचारात्मक इमेल छुट्टै सहमति र İYS दर्ताको सर्तमा मात्र पठाइन्छन्। पुस नोटिफिकेसन Apple (APNs) र Google (FCM) मार्फत पठाइन्छन्।
  • एनालिटिक्स औजार: तेस्रो पक्षको एनालिटिक्स औजार (जस्तै Google Analytics) प्रयोग गरिँदैन। एपभित्र उत्पादनको प्रयोग मापन हाल सक्रिय छैन; सक्रिय गरिएमा मापन Corenta को आफ्नै डेटाबेस (Supabase, Frankfurt/जर्मनी) मा राखिने पहिलो-पक्षको तालिकामा लेखिन्छ, यसमा स्वास्थ्य डेटा र स्वतन्त्र पाठ हुँदैन र सक्रिय गर्नुअघि यो नीति अद्यावधिक गरिन्छ; सक्रिय गरिएपछि मापनका अभिलेखको भण्डारण अवधि यस नीतिमा उल्लेख गरिन्छ।
  • त्रुटि अनुगमन: तेस्रो पक्षको त्रुटि अनुगमन औजार प्रयोग गरिँदैन; क्लाइन्ट-पक्षका त्रुटि Corenta को आफ्नै डेटाबेसमा अभिलेख गरिन्छन्।
  • वेबमार्फत प्रत्यक्ष क्रेडिट कार्डबाट भुक्तानीको पूर्वाधार छैन; भुक्तानी Apple/Google को एपभित्रको खरिद (IAP) संयन्त्रमार्फत मात्र गरिन्छ; अन्तिम बिल/रसिद Apple/Google ले जारी गर्छन् (हेर्नुहोस् भाग 4, क्रम 6)।

माथिका उप-प्रशोधकसँग डेटाको आदानप्रदान सम्बन्धित सेवा उपलब्ध गराउन आवश्यक हदसम्म मात्र र KVKK धारा 8/धारा 9 को ढाँचाभित्र गरिन्छ। विदेश स्थानान्तरण: माथिका सबै प्रदायकले टर्कीबाहिर डेटा प्रशोधन गर्छन्; जर्मनीमा होस्टिङ पनि KVKK को अर्थमा विदेश स्थानान्तरण हो। यी स्थानान्तरण नियमित र निरन्तर भएकाले स्पष्ट सहमतिमा आधारित गरिँदैनन्; धारा 9/4-c बमोजिम बोर्डले घोषणा गरेका मानक सम्झौतामा आधारित गरिनेछन्। यस पाठको मितिसम्म मानक सम्झौता अझै हस्ताक्षर भएका छैनन् र बोर्डलाई सूचित गरिएको छैन; प्रत्येक सम्झौता हस्ताक्षर भएको मितिदेखि 5 कार्यदिनभित्र बोर्डलाई सूचित गरिनेछ र यो तालिका मितिसहित अद्यावधिक गरिनेछ। बोर्डले यी देशबारे घोषणा गरेको पर्याप्तताको निर्णय छैन (अन्तिम जाँच: 11 अक्टोबर 2026)। यो सूची सेवा प्रदायकको परिवर्तनअनुसार अद्यावधिक हुन सक्छ; हालको सूची गोपनीयता नीति र/वा Corenta उत्पादनभित्रको सम्बन्धित जानकारी स्क्रिनबाट हेर्न सकिन्छ।

12. VERBİS दर्ता

यस कागजातको मितिसम्म Teta Studio को VERBİS दर्ता छैन। दर्ताको दायित्व बोर्डका निर्णय नं. 2025/1572 (मुख्य गतिविधि विशेष प्रकृतिको डेटा प्रशोधन भएका डेटा नियन्त्रकका लागि छुटको सीमा: वार्षिक 10 कर्मचारी र 10 मिलियन TL को वासलात) र 2025/2393 (वासलातको आधारमा खाता नराख्नेहरूका लागि कर्मचारी सङ्ख्याको मापदण्ड) का मापदण्डअनुसार मूल्याङ्कन गरिँदै छ। Teta Studio ले क्लिनिकको स्वास्थ्य डेटा डेटा नियन्त्रकका रूपमा होइन, डेटा प्रशोधकका रूपमा प्रशोधन गर्ने भएकाले, आफ्ना डेटा नियन्त्रकका गतिविधि (भाग A र C) का सम्बन्धमा मूल्याङ्कन यी मापदण्डबाट गरिन्छ। लिखित मूल्याङ्कन टिप्पणी र प्राधिकरण (ALO 198) को पुष्टि पूरा भएपछि यो भाग मिति र कारणसहित अद्यावधिक गरिनेछ; दर्ता आवश्यक भएमा गतिविधि जारी राख्नुअघि गरिनेछ।

भूमिकाअनुसारको स्पष्टीकरण: VERBİS मा दर्ताको दायित्व Corenta ले डेटा नियन्त्रकका रूपमा काम गर्ने कर्पोरेट वेबसाइट (corenta.app को अर्ली एक्सेस फारम) को सन्दर्भका लागि मूल्याङ्कन गरिँदै छ र यसको स्थिति माथि व्याख्या गरिएको छ। SaaS उत्पादनको सन्दर्भमा (app.corenta.app), क्लाइन्टको डेटाका सम्बन्धमा डेटा नियन्त्रक क्लिनिक भएकाले, VERBİS मा दर्ताको दायित्व छ वा छैन भन्ने कुरा प्रत्येक क्लिनिकको आफ्नै मापदण्ड (कर्मचारी सङ्ख्या, वार्षिक डेटा प्रशोधनको मात्रा, गतिविधिको क्षेत्र, बोर्डका छुटसम्बन्धी निर्णय आदि) अनुसार छुट्टै र स्वतन्त्र रूपमा मूल्याङ्कन गर्नुपर्छ; यो मूल्याङ्कन र दर्ताको दायित्व भए त्यो क्लिनिकको हो, Corenta लाई हस्तान्तरण गर्न सकिँदैन।

13. नीतिको अद्यावधिक

यो नीति कानूनका परिवर्तन, बोर्डका निर्णय, Corenta को प्राविधिक पूर्वाधारमा गरिने विकास (उदाहरणका लागि भाग 4 क्रम 3 र भाग 6.2 मा उल्लिखित सेसन नोटको स्वतन्त्र पाठको सामग्रीमा पाठभित्रको PII स्क्यानिङ थप्ने, भाग 5.4/भाग 4 क्रम 11 मा उल्लिखित स्पेसलिस्ट प्रमाणीकरणका कागजात (specialist-verification-docs) लाई tenant बन्द गर्ने प्रक्रियासँग जोड्ने, भाग 4 क्रम 10 र भाग 7 बुँदा 4 मा उल्लिखित पुस टोकन सफाइ प्रमाणित/लागू गर्ने, भाग 7 बुँदा 3 मा उल्लिखित अर्ली एक्सेस फारमको डेटाका लागि स्वचालित स्क्यानिङ संयन्त्र स्थापना गर्ने, भाग 8.2 मा उल्लिखित डेटा पोर्टेबिलिटीको प्रक्रिया विकास गर्ने, भाग 11 का विदेश स्थानान्तरणका कानुनी आधार पूरा गर्ने, उप-प्रशोधकको सूचीमा परिवर्तन) वा व्यावसायिक प्रक्रियाका परिवर्तनअनुसार अद्यावधिक हुन सक्छ। हालको संस्करण Corenta का सम्बन्धित प्लेटफर्ममा (कर्पोरेट वेबसाइट र/वा एपभित्र) प्रकाशित गरिन्छ र अघिल्लो संस्करणसँग बाझिने प्रावधानका सम्बन्धमा हालको संस्करणलाई आधार मानिन्छ। महत्त्वपूर्ण परिवर्तनमा, लागू हुने हदसम्म प्रयोगकर्ता/क्लिनिकलाई छुट्टै जानकारी पनि दिइन्छ।

14. सम्पर्क

यो नीति वा व्यक्तिगत डेटाको भण्डारण/निष्कासनसम्बन्धी तपाईंका प्रश्नका लागि:

इमेल: hello@corenta.app डेटा नियन्त्रक: Mertcan Demir — "Teta Studio" व्यापारिक नाममा सञ्चालित एकल स्वामित्वको व्यवसाय सपोर्ट: support@corenta.app सेवा क्षेत्र: Corenta, App Store र Google Play मार्फत, यी स्टोरले सेवा दिने देशहरूमा विश्वव्यापी रूपमा उपलब्ध छ। यस नीतिका अवधि हरेक देशका प्रयोगकर्तालाई लागू हुन्छन्; कुनै देशको अनिवार्य कानूनले छोटो मेटाउने वा लामो भण्डारणको दायित्व तोकेमा त्यही प्रावधान लागू हुन्छ।

अन्तिम पटक अद्यावधिक: 19 अक्टोबर 2026 संस्करण 1.9 · 19 अक्टोबर 2026

Sürüm bilgisi
Sürüm
1.9
sha256
f41ad424faa1a43879f26c59f8986c3a83094b3e1c0712e3344f1108d965f99d
Kaynak (TR) sha256
e923834cce3f0acab0b0eb1bdf599ae761c4e3ba6bc90a9ede9adc99e546fcbf