ஒரு நோயாளி “Disconnect My Data” என்று பெயரிடப்பட்ட பொத்தானைக் கிளிக் செய்கிறார். இணைய செயலி (web app) ஒரு பச்சை நிறச் சரிபார்ப்பு அடையாளத்தையும், மகிழ்ச்சியான உறுதிப்படுத்தலையும் காட்டுகிறது. பின்னணியில் இயங்கும் ஒரு பணி வரிசையில் (background queue), ஒரு பணிச் செயல்முறை (worker process) தனது இரவு நேரத் தரவு ஒத்திசைவிற்காக (nightly sync) விழித்துக்கொள்கிறது, நேற்று உருவாக்கப்பட்ட ஒரு பணியை எடுத்து, இரண்டு ஆண்டுகால மருந்துகள் வரலாற்றை ஒரு downstream analytics cluster-க்கு அனுப்பத் தொடங்குகிறது. பயனர் அந்த இடைமுகத்தை (interface) நம்பினார். ஆனால் அந்த அமைப்பு அந்த நம்பிக்கையைச் சிதைத்தது.
சுகாதாரத் தரவு கட்டமைப்பில் (health data architecture) இந்த குறிப்பிட்ட தோல்வி முறை மிகவும் அச்சமூட்டக்கூடியது, ஏனெனில் இதில் stakes மிக அதிகம். ஒரு காலாவதியான அனுமதி (stale permission) என்பது ஒரு சிறிய பிழை அல்ல; அது ஒரு நேரடி விதிமீறல் (active breach). இதற்கான தீர்வு என்பது ஒவ்வொரு தரவு கோரிக்கையையும் ஒரு 'சம்மத ரசீதுடன்' (consent receipt) இணைப்பதாகும்: இது ஒரு சிறிய, கட்டமைக்கப்பட்ட பதிவாகும், இது பயனரின் நோக்கத்தை UI-லிருந்து உங்கள் policy engine, உங்கள் தரவுத்தளப் பரிவர்த்தனைகள் (database transactions) மற்றும் ஒவ்வொரு பின்னணி பணிச் செயல்முறைக்கும் கொண்டு செல்கிறது. இது மருத்துவ மதிப்புகளைச் சேமிக்காது. மாறாக, அவற்றை அணுகும் உரிமையை மட்டுமே சேமிக்கும், மேலும் அந்த உரிமை பின்புலத்தில் ரகசியமாக மாற்ற முடியாத ஒரு பதிப்பு எண்ணுடன் (version number) முத்திரையிடப்பட்டிருக்கும்.
அந்த ரசீது உண்மையில் எதைக் கொண்டுள்ளது
அந்த ரசீதை ஒரு session flag ஆகக் கருதாமல், ஒரு வரம்புள்ள ஒப்பந்தமாக (scoped contract) கருதுங்கள். அதில் ஒரு அனுமதி அடையாளங்காட்டி (grant identifier), தரவுப் பொருள் (data subject), அணுகலின் துல்லியமான வரம்பு (ஆய்வக முடிவுகள், முக்கிய அறிகுறிகள், மருந்துகள் வரலாறு), காலவரையறை செய்யப்பட்ட செல்லுபடியாகும் காலம் மற்றும் ஒரு பதிப்பு எண் ஆகியவை இருக்கும். ஒரு frontend ஒரு பயனரின் சார்பாக அணுகலைக் கோரும்போது, API இந்த ரசீதை வழங்குகிறது. Frontend அதை வைத்திருக்கும். சுகாதாரத் தரவைப் படிக்க விரும்பும் ஒவ்வொரு downstream சேவையும், ஒரு மையக் கொள்கை அடுக்கிற்கு (central policy layer) அந்த ரசீதைக் காண்பித்து, பதிவைத் திறப்பதற்கு முன் தெளிவான அனுமதியைப் பெற வேண்டும்.
இது முக்கியமானது ஏனெனில் சுகாதார அமைப்புகள் பெரும்பாலும் ஒரு பயனர் கணக்கு டோக்கனை (user account token) சம்மதமாகக் கருதும் தவறு செய்கின்றன. ஒரு டோக்கன் நீங்கள் யார் என்று சொல்கிறது. ஒரு ரசீது நீங்கள் இப்போது என்ன செய்ய அனுமதிக்கப்படுகிறீர்கள் என்று சொல்கிறது. இவை இரண்டும் மாறுபட்டால், ரசீதின் முடிவே எப்போதும் இறுதியானது.
அனைத்தையும் பதிப்புப்படுத்துங்கள் (Version Everything)
உங்கள் சம்மதச் சேமிப்பகத்தை (consent store) ஒரு append-only log ஆக உருவாக்குங்கள். ஒரு பயனர் முதன்முதலில் தனது தடுப்பூசி பதிவுகளுக்கு அனுமதி அளிக்கும்போது, அது பதிப்பு ஒன்று (version one). அவர்கள் பின்னர் குறிப்பிட்ட வழங்குநர்களைத் தவிர்க்க வரம்பைக் குறைத்தால் அல்லது முழுமையாக ரத்து செய்தால், முதல் பதிவை மாற்ற வேண்டாம். பதிப்பு இரண்டை (version two) எழுதுங்கள். பணியாளரின் கையில் இருக்கும் ரசீது இன்னும் பதிப்பு ஒன்று என்றுதான் சொல்லும், மேலும் policy engine பதிப்பு ஒன்று எதற்கெல்லாம் அனுமதி அளித்தது என்பதையும், அது ஒரு குறிப்பிட்ட நேரத்தில் மாற்றப்பட்டது என்பதையும் துல்லியமாகப் பார்க்க முடியும்.
இந்த மாற்ற முடியாத தன்மை (immutability) உங்கள் தணிக்கை முதுகெலும்பாகும் (audit backbone). ஆறு மாதங்களுக்குப் பிறகு, ஒரு இணக்க அதிகாரி (compliance officer) ஏன் ஒரு குறிப்பிட்ட ETL பணி வியாழக்கிழமை மதியம் இயங்கியது என்று கேட்டால், அந்தப் பணி எந்தப் பதிப்பு அனுமதியைக் கொண்டு சென்றது என்பதை நீங்கள் கண்டறியலாம் மற்றும் பணி தொடங்கியபோது அது செல்லுபடியாகும் என்பதை நிரூபிக்கலாம். நீங்கள் ஒரு பயனர் சுயவிவரத்தில் சம்மதத்தை ஒரு ஒற்றை boolean flag ஆகச் சேமித்தால், அந்த வரலாற்றை நீங்கள் அழித்துவிடுகிறீர்கள். "இது ஒருபோதும் அனுமதிக்கப்படவில்லை" மற்றும் "பணி தொடங்கியபோது இது அனுமதிக்கப்பட்டது ஆனால் இரண்டு மணிநேரம் கழித்து பயனர் தனது முடிவை மாற்றிக்கொண்டார்" ஆகியவற்றுக்கு இடையேயான வேறுபாட்டைக் கண்டறியும் திறனை நீங்கள் இழக்கிறீர்கள்.
நேர்மையான முறையில் Endpoints-களை வடிவமைக்கவும்
ஒரு consent API தெளிவான மற்றும் குறிப்பிட்ட வழித்தடங்களை (routes) வெளிப்படுத்த வேண்டும். POST /grants ஒரு புதிய அனுமதியை உருவாக்கட்டும். GET /grants/{id} ஒரு குறிப்பிட்ட ரசீதின் தற்போதைய நிலையைத் திரும்பப் பெறட்டும். POST /grants/{id}/revoke ஒரு ரத்து செய்யும் செயல்முறையைத் தொடங்கட்டும். ரத்து செய்தவுடன் உங்கள் pipelines-இல் மிதந்து கொண்டிருக்கும் சுகாதாரத் தரவின் ஒவ்வொரு பிரதியையும் உடனடியாக அழித்துவிடுவதாகக் காட்டிக்கொள்ள வேண்டாம். அதற்குப் பதிலாக, ஒரு 202 Accepted நிலையுடன் ஒரு ரத்து செய்யும் செயல்முறை அடையாளங்காட்டியை (revocation operation ID) வழங்கவும். இது கோரிக்கை உண்மையானது, அது தொடங்குகிறது மற்றும் பயனரால் அதைத் கண்காணிக்க முடியும் என்பதைப் பயனருக்குத் தெரிவிக்கும்.
இடைமுகம் மெதுவாக இருப்பதாக உணர்ந்து பயனர் இருமுறை கிளிக் செய்யும்போது அந்த operation ID முக்கியமானது. அவர்கள் இரண்டாவது ரத்து கோரிக்கையைச் சமர்ப்பித்தால், அசல் operation ID-யையே வழங்கவும். இங்கே Idempotency என்பது ஒரு கூடுதல் வசதி அல்ல; அது தேவையற்ற பதற்றத்தைத் தடுக்கிறது மற்றும் பயனருக்கு அவர்களின் கோரிக்கையின் நிலை குறித்த ஒற்றை உண்மை ஆதாரத்தை (single source of truth) வழங்குகிறது.
கடைசி சாத்தியமான தருணத்தில் அனுமதியைக் கேளுங்கள்
API gateway-இல் சம்மதத்தைச் சரிபார்த்துவிட்டு, பின்னர் ஒரு worker-இன் ஆழத்தில் உள்ள ஒரு cached flag-ஐ நம்புவது ஒரு பொதுவான தவறு. இதைச் செய்யாதீர்கள். அந்த worker தனது பணிச் சுழற்சி (job lifecycle) முழுவதும் தனது ரசீதைக் கொண்டு செல்ல வேண்டும். சுகாதாரப் பதிவுச் சேமிப்பகத்திற்கு எதிராக வினவலை (query) இயக்குவதற்குச் சரியாக முன்னதாகவே, அது policy layer-இடம் கேட்க வேண்டும்: "இந்த குறிப்பிட்ட அனுமதியின் பதிப்பு மூன்று இன்னும் இந்தத் துல்லியமான வரம்பிற்கு செல்லுபடியாகுமா?" பதில் இல்லை என்றால், worker அந்தப் பணியை நிறுத்திவிடும். அது பணியைத் தோல்வியடையச் செய்யும். அது மீண்டும் முயற்சிக்காது (retry).
இங்கே retry logic என்பது நச்சு போன்றது. பதிப்பு முரண்பாடு (version mismatch) என்பது ஒரு நெட்வொர்க் பிழை அல்ல. அது ஒரு மனித முடிவு. பயனர் ரத்து செய்திருக்கலாம், அல்லது அனுமதி காலாவதியாகி இருக்கலாம், அல்லது வரம்பு குறைக்கப்பட்டிருக்கலாம். நீங்கள் மூன்று முறை முயற்சி செய்து, ஒரு race condition காரணமாக நான்காவது முறை வெற்றி பெற்றால், நீங்கள் சம்மதத்தை மீறிவிட்டீர்கள் என்று அர்த்தம். இந்த முரண்பாட்டை ஒரு கடினமான தோல்வியாக (hard failure) கருதுங்கள், அதை உங்கள் dead-letter queue அல்லது operations dashboard-க்கு அனுப்பி, ஒரு மனிதர் அதை ஆய்வு செய்ய அனுமதிக்கவும்.
சிக்கலான சூழல்களைக் கையாளவும்
நிஜ உலக அமைப்புகள் நேர்த்தியான படிகளில் இயங்குவதில்லை. பயனர்கள் பழைய பிரவுசர் டேப்களை (browser tabs) திறந்து விடுகிறார்கள். மொத்த இறக்குமதிகள் (Bulk imports) இருபது நிமிடங்கள் வரை இயங்குகின்றன. ஒரு ஒத்திசைவு (sync) பாதியிலேயே இருக்கும்போது ஸ்கோப்கள் (Scopes) மாறுகின்றன. இத்தகைய தருணங்களுக்காக உங்கள் consent API-க்கு தெளிவான விதிகள் தேவை.
பழைய பிரவுசர் டேப்கள் (Stale browser tabs). ஒரு பயனர் புதிதாகத் திறக்கப்பட்ட டேபில் அனுமதியைத் திரும்பப் பெறுகிறார். முந்தைய பக்கப் பதிவிலிருந்து (page load) ஒரு grant object-ஐ இன்னும் வைத்திருக்கும் ஒரு பழைய டேப், மீண்டும் இணைக்க முயற்சிக்கிறது. உங்கள் backend அந்தப் பழைய ரசீதை (stale receipt) உடனடியாக நிராகரிக்க வேண்டும் மற்றும் புதிய consent மதிப்பாய்வை மேற்கொள்ளக் கட்டாயப்படுத்த வேண்டும். ரத்து செய்யப்பட்ட ஒரு grant, ரத்து செய்யப்பட்ட கடவுச்சீட்டைப் போலச் செயல்பட வேண்டும்: அதன் உரிமையாளர் ஒரு பழைய நகலைத் தட்டில் கண்டெடுத்ததால் அது மீண்டும் உயிர் பெற்றுவிடக் கூடாது.
நடைபெற்றுக்கொண்டிருக்கும் இறக்குமதிகள் (In-flight imports). ஒரு மொத்த இறக்குமதி (bulk import) நடந்து கொண்டிருக்கும்போது பயனர் அனுமதியை ரத்து செய்தால், இரண்டு விஷயங்கள் ஒரே நேரத்தில் நடக்க வேண்டும். முதலாவதாக, அந்த வெர்ஷன் (version) நிராகரிக்கப்பட்ட அடுத்த கணமே புதிய தரவுப் பதிவுகளை (writes) அனுமதிப்பதை நிறுத்த வேண்டும். இரண்டாவதாக, operation ID மூலம் உண்மையான சுத்திகரிப்பு முன்னேற்றத்தை (cleanup progress) பயனருக்குக் காட்ட வேண்டும். அவர்களுக்கு ஒரு உண்மையான நிலைப்பக்கத்தைக் (status page) கொடுக்கவும்: “ரத்து செய்யப்பட்டது ஏற்றுக்கொள்ளப்பட்டது. பதினெட்டு நிலுவையில் உள்ள பதிவுகள் நீக்கப்பட்டு வருகின்றன.” ஏற்கனவே செல்லாதது எனத் தீர்மானிக்கப்பட்ட ஒரு grant version-ஐப் பயன்படுத்தி தரவுகளைச் சேமிக்க (commit) workers-களை அனுமதிக்காதீர்கள்.
ஸ்கோப் மாற்றங்கள் (Scope changes). ஒரு பயனர் முதலில் ஐந்து ஆண்டு கால வரலாற்றிற்கு அனுமதி அளித்துவிட்டு, பின்னர் அதை ஆறு மாதங்களாக மாற்றியமைப்பதாகக் கொள்வோம். அசல் grant-ஐ மாற்றாதீர்கள். வெர்ஷன் ஒன்றைத் (version one) துண்டித்துவிட்டு, குறுகிய கால வரம்பைக் கொண்ட வெர்ஷன் இரண்டை (version two) வழங்கவும், மேலும் தற்போது நடந்து கொண்டிருக்கும் அனைத்துச் செயல்பாடுகளையும் புதிய வரம்பிற்கு ஏற்பச் சரிசெய்யக் கட்டாயப்படுத்தவும். பழைய வெர்ஷன் உங்கள் லாக்-இல் (log) ஒரு வரலாற்றுத் தகவலாக மட்டுமே இருக்க வேண்டுமே தவிர, ஒரு செயல்பாட்டு அனுமதியாக (living permission) இருக்கக்கூடாது.
கடுமையான பாதுகாப்பு விதிகள்
ரசீத்கள் (Receipts) என்பவை முக்கியமானவை, ஆனால் அவை மருத்துவத் தரவுகள் (clinical data) அல்ல. உங்கள் கட்டமைப்பில் (architecture) அவற்றைத் தனித்துப் பிரித்து வைக்கவும். நோயாளி அல்லது சட்டப்பூர்வ பாதுகாவலர் அல்லது அங்கீகரிக்கப்பட்ட பராமரிப்பாளர் போன்ற ஒரு குறிப்பிட்ட பொறுப்பிற்கு வழங்கப்பட்ட நபர் மட்டுமே ஒரு ரசீதைக் காணவோ அல்லது ரத்து செய்யவோ முடிய வேண்டும். இதை UI routing table-இல் மட்டும் செய்யாமல், தரவு மட்டத்திலேயே (data layer) நடைமுறைப்படுத்தவும்.
வேலைகள் தோல்வியடையும் போது, உங்கள் error logs மருத்துவத் தரவுகளை உள்வாங்க முயற்சிக்கும். இந்தத் போக்கைத் தீவிரமாகத் தடுத்து நிறுத்துங்கள். ஒரு செல்லாத consent receipt-ஐ வழங்கியதால் ஒரு worker செயலிழக்கும்போது, grant ID, வெர்ஷன் மற்றும் பிழையை (error) மட்டும் பதிவு செய்யவும். நோயாளி அடையாளம் (patient identifier), நோய் கண்டறியும் குறியீடு (diagnosis code) அல்லது அந்த worker எடுக்க முயன்ற ஆய்வக மதிப்பு (lab value) ஆகியவற்றை ஒருபோதும் பதிவு செய்யாதீர்கள். லாக்-களில் உள்ள மருத்துவத் தரவுகள் பூஞ்சையைப் போலப் பரவும்: அவை பேக்கப் (backup) செய்யப்படுகின்றன, குறியீடாக்கம் (indexed) செய்யப்படுகின்றன மற்றும் உங்கள் சாதாரண அணுகல் கட்டுப்பாடுகளைத் தாண்டி மறக்கப்படுகின்றன.
இறுதியாக, கணினி மீட்புப் பணியின் (system recovery) போது பழைய செயல்பாட்டு grant-களை ஒருபோதும் மீட்டெடுக்காதீர்கள். நீங்கள் ஒரு தரவுத்தளத்தை (database) பழைய நிலைக்குக் கொண்டு சென்றாலோ (roll back) அல்லது ரத்து செய்வதற்கு முந்தைய grant table-ஐக் கொண்ட ஒரு snapshot-ஐ மீட்டெடுத்தாலோ, சேவை புதிய போக்குவரத்தை (traffic) ஏற்பதற்கு முன்பே, உங்கள் runbook தானாகவே அந்த மீண்டும் உயிர் பெற்ற அனுமதிகளை முடக்கிவிட வேண்டும். வரலாற்று ரீதியான consent நிலைகள் audit log-இல் மட்டுமே இருக்க வேண்டுமே தவிர, செயல்பாட்டு விதித் தொகுப்பில் (active rule set) இருக்கக்கூடாது.