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) സബ്-പ്രോസസർ/പ്രോസസർ രേഖകളിൽ നിന്ന് നീക്കം ചെയ്തു; push നോട്ടിഫിക്കേഷനുകൾ Apple (APNs), Google (FCM) എന്നിവ വഴി മാത്രം കൈമാറുന്നു, Expo/EAS ആപ്പ് ബിൽഡ് ഉപകരണം മാത്രമാണ്, അന്തിമ ഉപയോക്തൃ ഡാറ്റ പ്രോസസ് ചെയ്യുന്നില്ല.
• 1.5 — 10 ഒക്ടോബർ 2026: Google Analytics തിരഞ്ഞെടുപ്പുമായി ബന്ധപ്പെട്ട പ്രയോഗം നീക്കം ചെയ്തു; മൂന്നാം കക്ഷി അനലിറ്റിക്സ് ഉപയോഗിക്കുന്നില്ലെന്നും push പ്രോസസർമാർ ആരാണെന്നും വ്യക്തമാക്കി.
• 1.4 — 4 ഒക്ടോബർ 2026: നിലവിലെ വാചകം അംഗീകൃത പതിപ്പായി ഉറപ്പിച്ചു. ഈ പതിപ്പിൽ ഇവ മാത്രം ഉൾപ്പെടുത്തി: അക്കൗണ്ട് ഇല്ലാതാക്കൽ (ആക്സസ് ഉടൻ നിർത്തലാക്കുന്നു, വ്യക്തിഗത ഡാറ്റ ഇല്ലാതാക്കുകയോ അജ്ഞാതമാക്കുകയോ ചെയ്യുന്നു, നിയമപരമായി സൂക്ഷിക്കേണ്ട പേയ്മെന്റ് രേഖകൾ തിരിച്ചറിയൽ ഇല്ലാതെ സൂക്ഷിക്കുന്നു; പിൻവലിക്കാനുള്ള കാലയളവ് ഇല്ല); 30 ദിവസത്തിന്റെ അവസാനം ക്ലയന്റ് ആരോഗ്യ ഫീൽഡുകളുടെ ഇല്ലാതാക്കൽ; 7 ദിവസത്തെ അനാഥ രസീത് കാലയളവ്; സപ്പോർട്ട് ആക്സസിൽ ക്ലയന്റ് ബന്ധപ്പെടൽ വിവരങ്ങൾ മറഞ്ഞിരിക്കൽ; തിരിച്ചറിയൽ ഇല്ലാത്ത സെർവർ വശ അളക്കൽ; സേവന ഇമെയിലുകളും Google Workspace ഉം; push പ്രോസസർമാർ; സപ്പോർട്ട് വിലാസം; വിപണി (തുർക്കി).
• 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. ഡാറ്റ കൺട്രോളർ / ഡാറ്റ പ്രോസസർ വിവരങ്ങൾ

1.4. അടിസ്ഥാന നിയമനിർമ്മാണം

• 6698 നമ്പർ വ്യക്തിഗത ഡാറ്റ സംരക്ഷണ നിയമം,
• വ്യക്തിഗത ഡാറ്റ ഇല്ലാതാക്കൽ, നശിപ്പിക്കൽ അല്ലെങ്കിൽ അജ്ഞാതമാക്കൽ സംബന്ധിച്ച ചട്ടം (28.10.2017 തീയതിയിലെ 30224 നമ്പർ ഔദ്യോഗിക ഗസറ്റ്),
• വ്യക്തിഗത ഡാറ്റ ഇല്ലാതാക്കൽ, നശിപ്പിക്കൽ അല്ലെങ്കിൽ അജ്ഞാതമാക്കൽ മാർഗ്ഗനിർദ്ദേശവും വ്യക്തിഗത ഡാറ്റ സംരക്ഷണ ബോർഡിന്റെ ("ബോർഡ്") തീരുമാനങ്ങളും,
• 6102 നമ്പർ ടർക്കിഷ് വാണിജ്യ നിയമം (വാണിജ്യ ബുക്കുകളുടെയും രേഖകളുടെയും സൂക്ഷിക്കൽ),
• 213 നമ്പർ നികുതി നടപടിക്രമ നിയമം (സാമ്പത്തിക രേഖകളുടെ സൂക്ഷിക്കൽ),
• ബന്ധപ്പെട്ട മറ്റ് മേഖലാ നിയമനിർമ്മാണം (ബാധകമാകുന്ന അളവിൽ ആരോഗ്യ സേവന വിതരണവുമായി ബന്ധപ്പെട്ട നിയമനിർമ്മാണം ഉൾപ്പെടെ).

2. നിർവചനങ്ങൾ

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">

</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. ആരോഗ്യ ഡാറ്റയെക്കുറിച്ചുള്ള പ്രത്യേക കുറിപ്പ്

ആരോഗ്യ വിവര ഫോമുകൾ, സെഷൻ നോട്ടുകൾ, അളവ് രേഖകൾ തുടങ്ങിയ പ്രത്യേക വിഭാഗം ആരോഗ്യ ഡാറ്റയും മുകളിലെ പൊതു ഇല്ലാതാക്കൽ പ്രവാഹത്തിന് (soft-delete → 30 ദിവസം → സ്ഥിരമായ ഇല്ലാതാക്കൽ) വിധേയമാണ്; എന്നാൽ വിഭാഗം 4 ക്രമം 2-4 ലും വിഭാഗം 6.2 ലും വിശദീകരിച്ചതുപോലെ ഈ പട്ടികകളിൽ സ്ഥിരമായ ഇല്ലാതാക്കൽ ഘട്ടം വ്യക്തിയുമായുള്ള ബന്ധം വിച്ഛേദിക്കലും ഭാഗിക വൃത്തിയാക്കലും വഴി നടപ്പാക്കുന്നു — രേഖ DELETE ചെയ്യുന്നില്ല, വ്യക്തിയുമായുള്ള ബന്ധം വിച്ഛേദിക്കുകയും ചില സ്വതന്ത്ര വാചക ഫീൽഡുകൾ മായ്ക്കുകയും ചെയ്യുന്നു; ക്ലിനിക്കൽ രേഖ (പ്രത്യേകിച്ച് append-only സെഷൻ നോട്ട് ഉള്ളടക്കം) tenant ന്റെ വ്യക്തിയുമായുള്ള ബന്ധം വിച്ഛേദിച്ച രേഖയായി ആക്സസ് പരിമിതപ്പെടുത്തിയ രൂപത്തിൽ സൂക്ഷിക്കുന്നു, അജ്ഞാതമായി കണക്കാക്കുന്നില്ല. കൂടാതെ, ഈ ഡാറ്റ വിഭാഗം ഡാറ്റ കൺട്രോളർ എന്ന നിലയിൽ ക്ലിനിക് സൂക്ഷിക്കുന്ന രേഖകളുമായി ഇഴചേർന്നിരിക്കുന്നതിനാൽ, ഒരു ക്ലയന്റിന്റെ അക്കൗണ്ട്/ഡാറ്റ ഇല്ലാതാക്കൽ അഭ്യർത്ഥന, ക്ലിനിക്കിന്റെ സ്വന്തം നിയമപരമായ സൂക്ഷിക്കൽ ബാധ്യതകളുമായി (ഉദാഹരണത്തിന് ആരോഗ്യ സേവന വിതരണവുമായി ബന്ധപ്പെട്ട നിയമനിർമ്മാണത്തിൽ നിന്ന് ഉണ്ടായേക്കാവുന്ന രേഖ സൂക്ഷിക്കൽ നിർബന്ധങ്ങൾ) വൈരുദ്ധ്യത്തിലായേക്കാം; വ്യക്തിയുമായുള്ള ബന്ധം വിച്ഛേദിക്കലും പരിമിത സൂക്ഷിക്കലും എന്ന രീതി ഈ രണ്ട് ബാധ്യതകളെയും (വ്യക്തിഗത ഡാറ്റയിന്മേലുള്ള ക്ലയന്റിന്റെ അവകാശങ്ങളും ക്ലിനിക്കിന്റെ രേഖ സൂക്ഷിക്കൽ ബാധ്യതയും) സന്തുലിതമാക്കാൻ ലക്ഷ്യമിടുന്നു. ഇത്തരം സാഹചര്യങ്ങളിൽ അന്തിമ തീരുമാനമെടുക്കുന്ന അധികാരി, ഡാറ്റ കൺട്രോളർ എന്ന നിലയിൽ ക്ലിനിക്കാണ്; Corenta ക്ലിനിക്കിന്റെ നിർദ്ദേശത്തിന് അനുസൃതമായി പ്രവർത്തിക്കുന്നു.

5.6. ക്ലിനിക് (Tenant) തലത്തിലുള്ള ഇല്ലാതാക്കൽ

ഒരു ക്ലിനിക് Corenta സബ്സ്ക്രിപ്ഷൻ പൂർണ്ണമായി അവസാനിപ്പിക്കുകയാണെങ്കിൽ, ക്ലിനിക്കിന്റെ tenant ഡാറ്റയ്ക്കും ഈ tenant ന് കീഴിലുള്ള എല്ലാ ക്ലയന്റ് രേഖകൾക്കും ഇതേ രണ്ട് ഘട്ട (soft-delete → 30 ദിവസം → സ്ഥിരമായ ഇല്ലാതാക്കൽ) ഘടന ബാധകമാക്കുന്നു. ക്ലിനിക് സ്വന്തം ക്ലയന്റുകളുടെ ഡാറ്റ കൺട്രോളർ ആയതിനാൽ, സബ്സ്ക്രിപ്ഷൻ അവസാനിപ്പിക്കുന്നതിന് മുമ്പ് സ്വന്തം KVKK ബാധ്യതകളുടെ ചട്ടക്കൂടിനുള്ളിൽ ക്ലയന്റുകളെ അറിയിക്കാൻ ബാധ്യസ്ഥമാണ്; ഈ ബാധ്യത Corenta യ്ക്ക് കൈമാറാൻ കഴിയില്ല.

5.7. സൂപ്പർ-അഡ്മിൻ സപ്പോർട്ട് ആക്സസുമായുള്ള (ഇംപേഴ്സണേഷൻ) ബന്ധം

അക്കൗണ്ട് ഇല്ലാതാക്കൽ, സൂക്ഷിക്കൽ പ്രക്രിയകൾ Corenta യുടെ സപ്പോർട്ട്/ഇംപേഴ്സണേഷൻ സംവിധാനത്തിൽ നിന്ന് സ്വതന്ത്രമായി പ്രവർത്തിക്കുന്നു. ഇംപേഴ്സണേഷൻ ലോഗിനുകൾ സമയബന്ധിതമാണ് (30 മിനിറ്റ്), സ്ഥിരമായി വായന-മാത്രവുമാണ്; ആരോഗ്യ ഡാറ്റ വിഭാഗങ്ങളിലേക്കുള്ള (ആരോഗ്യ വിവരങ്ങൾ (അനാംനെസിസ്), സെഷൻ നോട്ട്, അളവ്) ആക്സസിന് പ്രത്യേക അംഗീകാര ഘട്ടം (health_data_enabled) ആവശ്യമാണ്, ഈ പട്ടികകളിലെ എഴുത്ത്/ഇല്ലാതാക്കൽ പ്രവർത്തനങ്ങൾക്ക് ഇംപേഴ്സണേഷൻ വഴി ഒരു സാഹചര്യത്തിലും അനുമതിയില്ല (RLS നയങ്ങളിൽ ഇംപേഴ്സണേഷന് ഒരു ഒഴിവും നൽകിയിട്ടില്ല). വ്യക്തത: ഇവിടെയുള്ള നിയന്ത്രണം, ഒരു സപ്പോർട്ട് സ്റ്റാഫ് ലോഗിൻ ചെയ്ത് നേരിട്ട് പ്രവർത്തനം നടത്തുന്ന മനുഷ്യൻ ട്രിഗർ ചെയ്യുന്ന ഇംപേഴ്സണേഷൻ ലോഗിനുകളുമായി ബന്ധപ്പെട്ടതാണ്; വിഭാഗം 5.2 ൽ വിശദീകരിച്ച സ്വയമേവയുള്ള (മനുഷ്യ ഇടപെടലില്ലാത്ത) service-role cron പ്രക്രിയ ഈ നിയന്ത്രണത്തിൽ നിന്ന് വേറിട്ട ഒരു തലമാണ്, അതിനാൽ ബാധിക്കപ്പെടുന്നില്ല — ഇംപേഴ്സണേഷൻ നിയന്ത്രണം, അക്കൗണ്ട് ഇല്ലാതാക്കൽ പ്രവാഹത്തിലെ സ്വയമേവയുള്ള സ്ഥിരമായ ഇല്ലാതാക്കൽ സംവിധാനത്തെ തടയുന്നില്ല, അതുമായി കൂട്ടിക്കലർത്തരുത്. അതിനാൽ അക്കൗണ്ട് ഇല്ലാതാക്കൽ/നിർമാർജന പ്രക്രിയകൾ ഈ നയത്തിൽ നിർവചിച്ചിരിക്കുന്ന സ്വയമേവയുള്ള സംവിധാനങ്ങൾ വഴി മാത്രമാണ് നടത്തുന്നത്.

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 തത്വവും അനുസരിച്ച്, tenant ന്റെ വ്യക്തിയുമായുള്ള ബന്ധം വിച്ഛേദിച്ച രേഖയായി സൂക്ഷിക്കുന്നത് തുടരുന്നു; സെഷൻ നോട്ടിന്റെ സ്വതന്ത്ര വാചകം മാറ്റാത്തതിനാൽ ഈ രേഖകൾ അജ്ഞാതമായി കണക്കാക്കുന്നില്ല, ആക്സസ് പരിമിതപ്പെടുത്തിയ രൂപത്തിൽ സൂക്ഷിക്കുന്നു.

സെഷൻ നോട്ടുകളിൽ (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. കാലാവധി തീർന്ന/അസാധുവായ push നോട്ടിഫിക്കേഷൻ ടോക്കണുകൾ പ്രത്യേകമായി സ്വയമേവയും ആനുകാലികമായും വൃത്തിയാക്കുന്നത് ഉൽപ്പന്ന റോഡ്മാപ്പിൽ ആസൂത്രണം ചെയ്ത ഒരു മെച്ചപ്പെടുത്തലാണ്; ഈ സംവിധാനം സിസ്റ്റത്തിൽ ഇപ്പോൾ യഥാർത്ഥത്തിൽ പ്രവർത്തിക്കുന്നുണ്ടെന്ന് സാങ്കേതികമായി സ്ഥിരീകരിച്ചിട്ടില്ല (വിഭാഗം 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).
• വിവര അഭ്യർത്ഥന / ഡാറ്റ പോർട്ടബിലിറ്റി: ഡാറ്റ ഉടമയുടെ സ്വന്തം 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. റോളുകളും ഉത്തരവാദിത്തങ്ങളും

10. സുരക്ഷാ നടപടികൾ (സൂക്ഷിക്കൽ കാലയളവിലുടനീളം)

വ്യക്തിഗത ഡാറ്റ സൂക്ഷിക്കൽ കാലയളവിലുടനീളം താഴെപ്പറയുന്ന സാങ്കേതിക, ഭരണപരമായ നടപടികൾ വഴി സംരക്ഷിക്കുന്നു (KVKK വകുപ്പ് 12):

• മൾട്ടി-ടെനന്റ് (multi-tenant) ഘടനയിൽ, ഓരോ പട്ടികയിലും tenant_id നിർബന്ധവും വരി തല സുരക്ഷാ (Row Level Security) നയങ്ങളും വഴി സ്ഥിരമായി നിരസിക്കൽ (default-deny) തത്വം നടപ്പാക്കുന്നു (37/37 പട്ടിക, 86 നയം); ടെനന്റുകൾക്കിടയിലുള്ള ഡാറ്റ ചോർച്ച ഇങ്ങനെ സാങ്കേതികമായി തടയുന്നു.
• ആരോഗ്യ ഡാറ്റ ഉൾക്കൊള്ളുന്ന പട്ടികകളിലേക്കുള്ള ആക്സസ്, ബന്ധപ്പെട്ട ക്ലയന്റ്, നിയോഗിക്കപ്പെട്ട സ്പെഷ്യലിസ്റ്റ്, tenant അഡ്മിൻ എന്നിവർക്ക് മാത്രമായി പരിമിതമാണ്; ആക്സസ് നിയന്ത്രണം ഡാറ്റാബേസ് തലത്തിൽ (RLS) നടപ്പാക്കുന്നു. സെഷൻ നോട്ടുകൾ അയച്ചതിന് ശേഷം മാറ്റാനോ ഇല്ലാതാക്കാനോ കഴിയില്ല (append-only); ആരോഗ്യ വിവര ഫോമുകൾക്ക് ഒരു ഉപയോക്താവിനും (അഡ്മിൻ ഉൾപ്പെടെ) ഇല്ലാതാക്കാനുള്ള അധികാരം നൽകിയിട്ടില്ല.
• സൂപ്പർ-അഡ്മിൻ സപ്പോർട്ട് ആക്സസ് (ഇംപേഴ്സണേഷൻ), സമയബന്ധിതമാണ് (30 മിനിറ്റ്), സ്ഥിരമായി വായന-മാത്രമാണ്; എഴുത്ത് പ്രവർത്തനങ്ങളും ആരോഗ്യ ഡാറ്റ ആക്സസും പ്രത്യേകവും അധിക അംഗീകാരം ആവശ്യമുള്ളതുമായ ഘട്ടങ്ങൾക്ക് വിധേയമാണ്; ഒരു ഇംപേഴ്സണേഷൻ സാഹചര്യത്തിലും ആരോഗ്യ ഡാറ്റ പട്ടികകളിലേക്ക് എഴുത്ത് ആക്സസ് തുറക്കുന്നില്ല. (ഈ നിയന്ത്രണം മനുഷ്യൻ ട്രിഗർ ചെയ്യുന്ന ഇംപേഴ്സണേഷൻ ലോഗിനുകളുമായി ബന്ധപ്പെട്ടതാണ്; സ്വയമേവയുള്ള service-role cron പ്രക്രിയകൾ വേറിട്ട ഒരു തലമാണ് — വിഭാഗം 5.7 കാണുക.)
• ഡാറ്റ കൈമാറ്റത്തിൽ എൻഡ്-ടു-എൻഡ് എൻക്രിപ്ഷൻ (TLS) ഉപയോഗിക്കുന്നു; മൊബൈൽ ആപ്പിൽ ലോഗിൻ ടോക്കണുകൾ ഉപകരണത്തിന്റെ സുരക്ഷിത ഹാർഡ്‌വെയർ പിന്തുണയുള്ള കീ സംഭരണിയിൽ (Keychain/Keystore) എൻക്രിപ്റ്റ് ചെയ്ത് സൂക്ഷിക്കുന്നു.
• സെൻസിറ്റീവ് സ്ക്രീനുകളിൽ സ്ക്രീൻഷോട്ട് എടുക്കുന്നത് പരിമിതപ്പെടുത്താനുള്ള സാങ്കേതിക നടപടികൾ സ്വീകരിച്ചിട്ടുണ്ട്.
• സൂപ്പർ-അഡ്മിൻ അക്കൗണ്ടുകൾക്ക് രണ്ട് ഘടക തിരിച്ചറിയൽ സ്ഥിരീകരണം (2FA/MFA) നിർബന്ധമാണ്.
• പേയ്മെന്റ് പ്രവർത്തനങ്ങളുമായി ബന്ധപ്പെട്ട അറിയിപ്പുകളുടെ (webhook) ക്രിപ്റ്റോഗ്രാഫിക് ഒപ്പ് സ്ഥിരീകരണം ഘടനയിൽ വിഭാവനം ചെയ്യുകയും നടപ്പാക്കുകയും ചെയ്യുന്നു; ബന്ധപ്പെട്ട കോൺഫിഗറേഷൻ/കീ മാനേജ്മെന്റ് എല്ലാ പരിതസ്ഥിതികളിലും (prod ഉൾപ്പെടെ) പൂർണ്ണമായി പൂർത്തിയാക്കുന്നതിനുള്ള പ്രവർത്തനം തുടരുന്നു.
• ഈ സുരക്ഷാ നടപടികൾ തുടർച്ചയായി അവലോകനം ചെയ്യുകയും മെച്ചപ്പെടുത്തുകയും ചെയ്യുന്നു; എന്നാൽ ഒരു സാങ്കേതിക നടപടിയും സമ്പൂർണ്ണ സുരക്ഷ ഉറപ്പ് നൽകുന്നില്ല, ഈ നയത്തിന്റെ പരിധിയിൽ സമ്പൂർണ്ണ സുരക്ഷാ പ്രതിബദ്ധത നൽകുന്നില്ല.

11. സബ്-പ്രോസസർമാരും ഡാറ്റ ലോക്കലൈസേഷനും

വ്യക്തിഗത ഡാറ്റ, സൂക്ഷിക്കൽ കാലയളവിലുടനീളം താഴെപ്പറയുന്ന സബ്-പ്രോസസർമാർ/സേവന ദാതാക്കൾ വഴി പ്രോസസ് ചെയ്യുകയോ ഹോസ്റ്റ് ചെയ്യുകയോ ചെയ്യുന്നു. ഈ ദാതാക്കളുമായുള്ള കരാറുകളിൽ, വ്യക്തമാക്കിയ സേവനത്തിന്റെ നിർവ്വഹണത്തിനായി മാത്രം ഡാറ്റ പ്രോസസ് ചെയ്യുന്നതിനുള്ള ബാധ്യതകൾ നിർദ്ദേശിക്കുന്നു; ഈ ബന്ധം സൂക്ഷിക്കൽ കാലയളവുകളെയല്ല, ഡാറ്റ ഹോസ്റ്റ് ചെയ്യുന്ന സാങ്കേതിക പരിതസ്ഥിതിയെയാണ് സൂചിപ്പിക്കുന്നത് — നിർമാർജന തീരുമാനത്തിന്റെ നടപ്പാക്കൽ ഈ ദാതാക്കളുടെ അടുത്തും സാങ്കേതികമായി നടക്കുന്നു. താഴെയുള്ള പട്ടിക, KVKK വകുപ്പ് 11/4 ന്റെ പരിധിയിലുള്ള "ഡാറ്റ കൈമാറിയ മൂന്നാം കക്ഷികളെ അറിയാനുള്ള" അവകാശത്തിനുള്ള മറുപടി കൂടിയാണ്:

കൂടാതെ:

• ഇമെയിൽ അടിസ്ഥാന സൗകര്യം: സേവന ഇമെയിലുകൾ Google Workspace (Google) വഴി അയയ്ക്കുന്നു; തിരിച്ചറിയൽ സ്ഥിരീകരണ ഇമെയിലുകൾ Supabase Auth ട്രിഗർ ചെയ്യുന്നു. പ്രൊമോഷണൽ ഇമെയിലുകൾ പ്രത്യേക സമ്മതവും İYS രജിസ്ട്രേഷനും എന്ന വ്യവസ്ഥയോടെ മാത്രം അയയ്ക്കുന്നു. Push നോട്ടിഫിക്കേഷനുകൾ 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) tenant അടയ്ക്കൽ പ്രക്രിയയുമായി ബന്ധിപ്പിക്കൽ, വിഭാഗം 4 ക്രമം 10 ലും വിഭാഗം 7 ഇനം 4 ലും പറഞ്ഞിരിക്കുന്ന push ടോക്കൺ വൃത്തിയാക്കലിന്റെ സ്ഥിരീകരണം/പ്രാബല്യത്തിൽ കൊണ്ടുവരൽ, വിഭാഗം 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