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/फ्रँकफर्ट हे परदेशी हस्तांतरण नाही" हा उल्लेख काढला आणि परदेशी हस्तांतरणाचा विभाग कायदा क्रमांक 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 प्लॅटफॉर्म सबस्क्रिप्शनद्वारे वापरणारी क्लिनिकल पिलाटेस, फिजिओथेरपी, रिफॉर्मर, वेलनेस/मसाज आणि योग केंद्रे ("टेनंट", "बिझनेस" किंवा "क्लिनिक") स्वतःच्या क्लायंटचा ("डेटा विषय क्लायंट") जो वैयक्तिक डेटा (संपर्क माहिती, एनामनेसिस, सेशन नोट, अपॉइंटमेंट/पॅकेज डेटा इत्यादी) प्लॅटफॉर्ममध्ये टाकतात त्याच्या बाबतीत क्लिनिक KVKK च्या कलम 3 नुसार डेटा नियंत्रक आहे; Corenta/Teta Studio फक्त डेटा प्रोसेसर म्हणून, क्लिनिकच्या सूचनांनुसार तांत्रिक पायाभूत सुविधेची सेवा देते. क्लायंटना माहिती देण्याचे बंधन, स्पष्ट संमती घेणे आणि क्लायंट डेटासंबंधीचा अंतिम जतन/विल्हेवाटीचा निर्णय क्लिनिकची कायदेशीर जबाबदारी आहे. Corenta ही बंधने पूर्ण करणे प्रॉडक्टमध्ये (संमती नोंद यंत्रणा consent_logs, मोबाइल KVKK मंजुरी स्क्रीन kvkk.tsx, ऑडिट ट्रेल) तांत्रिकदृष्ट्या सोपे करते, पण क्लिनिकचे KVKK अनुपालनाचे बंधन स्वतःकडे घेत नाही किंवा स्वीकारत नाही. या धोरणात या संदर्भासाठी स्पष्ट केलेले जतन कालावधी हे दाखवतात की Corenta डेटा प्रोसेसर म्हणून स्वतःच्या पायाभूत सुविधेत हा डेटा प्रत्यक्षात किती काळ ठेवते; अंतिम विल्हेवाटीचा निर्णय आणि कालावधी क्लिनिकची सूचना आणि त्याला लागू असलेल्या कायद्याच्या चौकटीत ठरू शकतो.

हे धोरण याशिवाय Corenta चे कर्मचारी, व्यावसायिक भागीदार आणि पुरवठादार यांच्या वैयक्तिक डेटाच्या जतन/विल्हेवाट प्रक्रियांनाही सामान्य तत्त्वांच्या दृष्टीने लागू होते; मात्र, धोरणाचा मुख्य भर वरील उपकलम (a) आणि (b) मध्ये व्याख्या केलेल्या सबस्क्रायबर/क्लायंट डेटावर आहे.

1.3. डेटा नियंत्रक / डेटा प्रोसेसरची माहिती

1.4. आधारभूत कायदे

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

2. व्याख्या

3. जतन आणि विल्हेवाटीचा कालावधी ठरवण्याचे निकष (KVKK कलम 5, कलम 6)

3.1. जतन आवश्यक करणारी कारणे

Corenta मध्ये वैयक्तिक डेटा फक्त संबंधित कायद्यात स्पष्टपणे निश्चित केलेल्या कालावधीइतका किंवा तो ज्या हेतूसाठी प्रोसेस होतो त्या हेतूसाठी आवश्यक कालावधीइतका जपून ठेवला जातो. जतन कालावधी ठरवताना पुढील निकष आधार म्हणून घेतले जातात:

1. कायदेशीर जतनाचे बंधन आहे का? (उदा. तुर्की वाणिज्य संहिता, कर कार्यपद्धती कायद्यांतर्गत आर्थिक नोंदींसाठी किमान जतन कालावधी.)
2. डेटा कोणत्या हेतूने प्रोसेस झाला आहे आणि हा हेतू अजूनही वैध आहे का? (KVKK कलम 5(2) — हेतूपुरती मर्यादा हे तत्त्व.)
3. कराराची निर्मिती/अंमलबजावणी यासाठी तो आवश्यक आहे का? (उदा. सबस्क्रिप्शन/सेवा संबंध चालू असेपर्यंत अपॉइंटमेंट आणि पॅकेज डेटा.)
4. हक्काची स्थापना, वापर किंवा संरक्षण यासाठी (संभाव्य कायदेशीर वादात पुरावा म्हणून) तो आवश्यक आहे का? (करार संहितेच्या (Borçlar Kanunu) सामान्य मुदत-मर्यादा लक्षात घेऊन.)
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">

</div>

नोंद 1: वरील तक्त्यातील "खाते/टेनंट सक्रिय असेपर्यंत" याचा अर्थ संबंधित क्लिनिकचे 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) हटवल्या जात नाहीत, व्यक्तीशी असलेला संबंध तोडला जातो — व्यक्तीशी असलेला संबंध डेटाबेस पातळीवर तोडला जातो, काही मुक्त-मजकूर फील्ड साफ केली जातात, नोंद टेनंटची व्यक्तीशी असलेला संबंध तोडलेली नोंद म्हणून मर्यादित ॲक्सेससह राहते (सेशन नोटचा मुक्त मजकूर बदलला जात नसल्यामुळे अनामिक मानली जात नाही) (पहा विभाग 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) क्षेत्रात ठेवलेल्या फाइल जोडण्या पुढीलप्रमाणे हाताळल्या जातात: अवतार/प्रोफाइल फोटो, एनामनेसिस फॉर्मला जोडलेले दस्तऐवज/फोटो आणि पेमेंटच्या पावतीची प्रतिमा, कायमच्या हटवण्याच्या पायरीचा भाग म्हणून Storage मधून आपोआप (best-effort) हटवल्या जातात — हे सिस्टममध्ये सध्या प्रत्यक्ष चालणारे, पडताळलेले वर्तन आहे. एखाद्या बकेटमधील हटवण्याची क्रिया अयशस्वी झाल्यास ती लॉग केली जाते; पण ती इतर बकेटच्या स्वच्छतेला किंवा खात्याच्या अनामिकीकरण/कायमच्या हटवण्याच्या पायऱ्यांना अडथळा आणत नाही (best-effort रचना).

प्रामाणिक मर्यादा: या आपोआप प्रक्रियेच्या व्याप्तीबाहेर राहणारी एकमेव फाइल श्रेणी म्हणजे स्पेशालिस्ट/सोलो-नोंदणी प्रक्रियेत अपलोड केलेले ओळख/पदवी पडताळणीचे दस्तऐवज (specialist-verification-docs बकेट). हे दस्तऐवज तांत्रिकदृष्ट्या वापरकर्त्याशी नव्हे, तर संबंधित टेनंटच्या (क्लिनिकच्या) पडताळणी प्रक्रियेशी जोडलेले आहेत आणि डेटाबेस नोंदीत वापरकर्त्याचा संदर्भ नसतो; त्यामुळे सध्याच्या वापरकर्ता-खाते-हटवण्याच्या प्रवाहात ते आपोआप समाविष्ट करता येत नाहीत. या दस्तऐवजाची विल्हेवाट संबंधित क्लिनिकने टेनंट पातळीवर स्वतःचे खाते/सबस्क्रिप्शन बंद करण्याच्या प्रक्रियेत स्वतंत्रपणे हाताळली जाईल (पहा विभाग 5.6); ते पूर्ण होईपर्यंत अपवादात्मक विनंत्यांचे hello@corenta.app द्वारे मॅन्युअल मूल्यमापन केले जाते.

त्यामुळे या धोरणात खाते हटवण्याच्या विनंतीसोबत "वापरकर्त्याचा सर्व डेटा/सर्व फाइल्स पूर्णपणे आणि लगेच हटवल्या जातात" अशी कोणतीही संपूर्ण बांधिलकी दिली जात नाही (विशेषतः बॅकअपमधील तांत्रिक अवशेषांसाठी पहा विभाग 6.3, आणि वरील अपवादासाठी); मात्र, वर वर्णन केलेल्या फाइल श्रेणींसाठी आपोआप हटवणे प्रत्यक्षात लागू केले जाते.

5.5. आरोग्य डेटाबद्दल विशेष नोंद

एनामनेसिस फॉर्म, सेशन नोट आणि मोजमापाच्या नोंदी यांसारखा विशेष श्रेणीतील आरोग्य डेटासुद्धा वरील सामान्य हटवण्याच्या प्रवाहाच्या (soft-delete → 30 दिवस → कायमचे हटवणे) अधीन आहे; मात्र, विभाग 4 क्रम 2-4 आणि विभाग 6.2 मध्ये स्पष्ट केल्याप्रमाणे, या टेबलमध्ये कायमच्या हटवण्याची पायरी व्यक्तीशी असलेला संबंध तोडून आणि अंशतः स्वच्छता करून लागू केली जाते — नोंद DELETE केली जात नाही, व्यक्तीशी असलेला संबंध तोडला जातो आणि काही मुक्त-मजकूर फील्ड साफ केली जातात; क्लिनिकल नोंद (विशेषतः append-only सेशन नोटचा मजकूर) टेनंटची व्यक्तीशी असलेला संबंध तोडलेली नोंद म्हणून मर्यादित ॲक्सेससह जतन केली जाते आणि अनामिक मानली जात नाही. याशिवाय, ही डेटा श्रेणी क्लिनिकने डेटा नियंत्रक म्हणून ठेवलेल्या नोंदींशी गुंतलेली असल्यामुळे, क्लायंटची खाते/डेटा हटवण्याची विनंती क्लिनिकच्या स्वतःच्या कायदेशीर जतनाच्या बंधनांशी (उदा. आरोग्य सेवा देण्यासंबंधीच्या कायद्यांमधून निर्माण होऊ शकणारी नोंदी ठेवण्याची बंधने) संघर्ष करू शकते; व्यक्तीशी असलेला संबंध तोडण्याची आणि मर्यादित जतनाची पद्धत या दोन बंधनांमध्ये (वैयक्तिक डेटावरील क्लायंटचे हक्क आणि क्लिनिकचे नोंदी ठेवण्याचे बंधन) संतुलन साधण्याचा हेतू ठेवते. अशा प्रकरणांमध्ये अंतिम निर्णय घेणारा प्राधिकारी डेटा नियंत्रक म्हणून क्लिनिक आहे; Corenta क्लिनिकच्या सूचनेनुसार काम करते.

5.6. क्लिनिक (टेनंट) पातळीवर हटवणे

एखाद्या क्लिनिकने त्याचे Corenta सबस्क्रिप्शन पूर्णपणे संपवल्यास, क्लिनिकचा टेनंट डेटा आणि या टेनंटखालील सर्व क्लायंटच्या नोंदींसाठीसुद्धा तीच दोन टप्प्यांची (soft-delete → 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 soft-delete प्रक्रियेत लागू केली जाते: डेटा डेटाबेसमधून प्रत्यक्ष काढला गेला नाही तरी, ॲक्सेसचे अधिकार आणि इंटरफेसद्वारे पूर्णपणे ॲक्सेस करता न येणारा केला जातो.

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 तत्त्वामुळे टेनंटची व्यक्तीशी असलेला संबंध तोडलेली नोंद म्हणून जतन होत राहतो; सेशन नोटचा मुक्त मजकूर बदलला जात नसल्यामुळे या नोंदी अनामिक मानल्या जात नाहीत आणि मर्यादित ॲक्सेससह जतन केल्या जातात.

सेशन नोटमध्ये (session_notes) append-only मर्यादा मजकुरातील बदलाला परवानगी देत नाही; फक्त व्यक्तीशी असलेल्या संबंधाचे कॉलम (client_id, specialist_id) NULL करण्यासाठी अरुंद, एकाच हेतूसाठीचा अपवाद दिला आहे — नोटचा मजकूर स्वतः या प्रक्रियेतही कोणत्याही टप्प्यावर हटवला किंवा बदलला जात नाही.

मर्यादा: मुक्त-मजकूर फील्डमध्ये स्पष्ट ओळखीच्या कॉलमशिवाय येऊ शकणाऱ्या मजकुरातील वैयक्तिक डेटासाठी (उदा. सेशन नोटच्या मुख्य भागात आलेले नाव) स्कॅन/स्वच्छतेची कोणतीही यंत्रणा नाही. त्यामुळे या नोंदी अनामिक मानल्या जात नाहीत; वैयक्तिक डेटा म्हणून मर्यादित ॲक्सेससह जतन केल्या जातात आणि कालावधी संपल्यावर त्यांची विल्हेवाट लावली जाते.

वरील दोन्ही पद्धती service-role ने संरक्षित असल्यामुळे सामान्य प्रॉडक्ट इंटरफेसद्वारे ट्रिगर करता येत नाहीत किंवा परत फिरवता येत नाहीत.

6.3. बॅकअपमधून (Backup) हटवणे

डेटाबेस बॅकअप सामान्य बॅकअप चक्राच्या (रोटेशन) चौकटीत ठराविक कालावधीनंतर आपोआप ओव्हरराइट/नष्ट होतात. कायमच्या हटवण्याची क्रिया प्राथमिक डेटाबेसमध्ये लगेच प्रभावी होत असली तरी, आधी घेतलेल्या बॅकअपमध्ये डेटा, बॅकअप पुरवठादाराचा (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 मध्ये स्पष्ट केलेल्या दोन टप्प्यांच्या (तात्काळ soft-delete → 30 दिवस → कायमचे हटवणे) प्रक्रियेद्वारे आपोआप पूर्ण केली जाते (कलम 11(6)).
• माहितीची विनंती / डेटा पोर्टेबिलिटी: डेटा विषयाच्या स्वतःच्या टेनंटच्या व्याप्तीतील डेटा संरचित, मशीनद्वारे वाचता येणाऱ्या फॉरमॅटमध्ये, वाजवी कालावधीत त्याला देऊन पूर्ण केली जाते (export_user_data फंक्शन, टेनंट-व्याप्ती पडताळलेली आहे). या प्रक्रियेची सुपूर्द यंत्रणा (फाइल फॉरमॅट, सुपूर्द करण्याची पद्धत, स्वाक्षरी केलेली डाउनलोड लिंक यांसारखी वैशिष्ट्ये) सतत विकसित केली जात आहे; या धोरणांतर्गत कोणत्याही ठराविक सुपूर्द कालावधीची किंवा विशिष्ट फाइल/ॲक्सेस फॉरमॅटची बांधिलकी दिली जात नाही (कलम 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. भूमिका आणि जबाबदाऱ्या

10. सुरक्षा उपाय (जतन कालावधीत)

जतन कालावधीत वैयक्तिक डेटा पुढील तांत्रिक आणि प्रशासकीय उपायांनी संरक्षित ठेवला जातो (KVKK कलम 12):

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

11. सब-प्रोसेसर आणि डेटाचे स्थानिकीकरण

जतन कालावधीत वैयक्तिक डेटा पुढील सब-प्रोसेसर/सेवा पुरवठादारांद्वारे प्रोसेस किंवा होस्ट केला जातो. या पुरवठादारांसोबतच्या करारांमध्ये डेटा फक्त सांगितलेल्या सेवेच्या अंमलबजावणीच्या हेतूने प्रोसेस व्हावा यासंबंधीची बंधने निश्चित केली आहेत; हा संबंध जतन कालावधी नव्हे, तर डेटा जिथे होस्ट होतो ते तांत्रिक वातावरण दर्शवतो — विल्हेवाटीच्या निर्णयाची अंमलबजावणी या पुरवठादारांकडेही तांत्रिकदृष्ट्या होते. पुढील तक्ता KVKK च्या कलम 11(4) अंतर्गत "डेटा ज्या तृतीय व्यक्तींना हस्तांतरित झाला आहे त्यांना जाणण्याच्या" हक्काचे उत्तरही आहे:

याशिवाय:

• ईमेल पायाभूत सुविधा: सेवा ईमेल Google Workspace (Google) द्वारे पाठवले जातात; ओळख पडताळणीचे ईमेल Supabase Auth द्वारे ट्रिगर होतात. प्रमोशनल ईमेल फक्त स्वतंत्र मंजुरी आणि İYS नोंदणीच्या अटीवर पाठवले जातात. पुश नोटिफिकेशन Apple (APNs) आणि Google (FCM) द्वारे पाठवले जातात.
• ॲनालिटिक्स साधन: तृतीय पक्षाचे कोणतेही ॲनालिटिक्स साधन (उदा. Google Analytics) वापरले जात नाही. ॲपमधील प्रॉडक्ट वापराचे मोजमाप सध्या सक्रिय नाही; सक्रिय केल्यास, मोजमाप Corenta च्या स्वतःच्या डेटाबेसमध्ये (Supabase, फ्रँकफर्ट/जर्मनी) ठेवलेल्या फर्स्ट-पार्टी टेबलमध्ये लिहिले जाईल, त्यात आरोग्य डेटा आणि मुक्त मजकूर नसेल, आणि सक्रिय करण्यापूर्वी हे धोरण अपडेट केले जाईल; सक्रिय झाल्यावर मोजमापाच्या नोंदींचा जतन कालावधी या धोरणात सांगितला जाईल.
• त्रुटी मॉनिटरिंग: तृतीय पक्षाचे त्रुटी मॉनिटरिंग साधन वापरले जात नाही; क्लायंट ॲपच्या त्रुटी 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) टेनंट बंद करण्याच्या प्रक्रियेशी जोडणे, विभाग 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