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 મહિને સામયિક નિકાલ લાગુ કરે છે અને દરેક ચક્ર માટે નિકાલનો અહેવાલ (minutes) તૈયાર કરે છે. આ ચક્રોને ઑટોમેટ કરતાં સમયપત્રક મુજબનાં કાર્યો હજી નથી; ચક્રો મેન્યુઅલી ચલાવવામાં આવે છે.

સામયિક નિકાલની પ્રક્રિયા, આ નીતિમાં જણાવેલી મુદતોથી સ્વતંત્ર રીતે, ડેટા વિષય 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