એક દર્દી “Disconnect My Data” લેબલવાળા બટન પર ક્લિક કરે છે. વેબ એપ એક લીલું ચેકમાર્ક અને આનંદદાયક પુષ્ટિ (confirmation) બતાવે છે. બેકગ્રાઉન્ડ ક્યુમાં ક્યાંક, એક વર્કર પ્રોસેસ તેની રાત્રિની સિંક (nightly sync) માટે જાગે છે, ગઈકાલે બનાવેલી જોબ ખેંચે છે, અને ડાઉનસ્ટ્રીમ એનાલિટિક્સ ક્લસ્ટરને બે વર્ષનો દવાઓનો ઇતિહાસ (medication history) સ્ટ્રીમ કરવાનું શરૂ કરે છે. વપરાશકર્તાએ ઇન્ટરફેસ પર વિશ્વાસ કર્યો હતો. સિસ્ટમે તે વિશ્વાસનો ભંગ કર્યો.
આ ચોક્કસ નિષ્ફળતાની રીત (failure mode) હેલ્થ ડેટા આર્કિટેક્ચર માટે મોટો પડકાર છે કારણ કે તેમાં જોખમ ઘણું વધારે છે. જૂની થઈ ગયેલી પરવાનગી (stale permission) એ કોઈ નાની ભૂલ નથી; તે એક સક્રિય ઉલ્લંઘન (active breach) છે. તેનો ઉકેલ એ છે કે દરેક ડેટા વિનંતીને 'કન્સેન્ટ રિસીપ્ટ' (consent receipt) સાથે જોડવી: એક નાનો, માળખાગત રેકોર્ડ જે વપરાશકર્તાના ઈરાદાને UI થી લઈને તમારા પોલિસી એન્જિન, તમારા ડેટાબેઝ ટ્રાન્ઝેક્શન અને દરેક બેકગ્રાઉન્ડ વર્કર સુધી પહોંચાડે છે. તે ક્યારેય ક્લિનિકલ મૂલ્યોનો સંગ્રહ કરતું નથી. તે ફક્ત તેમાં પ્રવેશવાનો અધિકાર સંગ્રહિત કરે છે, જે એક એવા વર્ઝન સાથે સ્ટેમ્પ થયેલ હોય છે જે પડદા પાછળથી બદલાઈ ન શકે.
રિસીપ્ટમાં ખરેખર શું હોય છે
રિસીપ્ટને સેશનની ફ્લેગ (session flag) તરીકે નહીં, પણ સ્કોપ્ડ કોન્ટ્રાક્ટ (scoped contract) તરીકે ગણો. તેમાં ગ્રાન્ટ આઈડેન્ટિફાયર (grant identifier), ડેટા સબ્જેક્ટ, એક્સેસનો ચોક્કસ સ્કોપ (લેબ રિઝલ્ટ, વાઈટલ્સ, મેડિકેશન હિસ્ટ્રી), સમયમર્યાદાવાળી માન્યતા વિન્ડો અને વર્ઝન નંબર હોય છે. જ્યારે ફ્રન્ટએન્ડ વપરાશકર્તા વતી એક્સેસ માટે વિનંતી કરે છે, ત્યારે API આ રિસીપ્ટ ઇશ્યૂ કરે છે. ફ્રન્ટએન્ડ તેને સાચવે છે. જે પણ ડાઉનસ્ટ્રીમ સર્વિસ હેલ્થ ડેટા વાંચવા માંગતી હોય તેણે સેન્ટ્રલ પોલિસી લેયર સમક્ષ રિસીપ્ટ રજૂ કરવી જોઈએ અને રેકોર્ડ ખોલતા પહેલા સ્પષ્ટ મંજૂરી મેળવવી જોઈએ.
આ મહત્વનું છે કારણ કે હેલ્થ સિસ્ટમ્સ ઘણીવાર યુઝર એકાઉન્ટ ટોકનને સંમતિ (consent) સમજવાની ભૂલ કરે છે. ટોકન કહે છે કે તમે કોણ છો. રિસીપ્ટ કહે છે કે તમે અત્યારે શું કરી શકો છો તેની પરવાનગી છે. જો આ બંને વચ્ચે તફાવત આવે, તો રિસીપ્ટ હંમેશા માન્ય રહેવી જોઈએ.
બધું જ વર્ઝન કરો
તમારા કન્સેન્ટ સ્ટોરને 'એપેન્ડ-ઓન્લી લોગ' (append-only log) તરીકે બનાવો. જ્યારે વપરાશકર્તા પહેલીવાર તેમના રસીકરણના રેકોર્ડ્સ (immunization records) માટે પરવાનગી આપે છે, ત્યારે તે વર્ઝન વન છે. જો તેઓ પાછળથી ચોક્કસ પ્રોવાઇડર્સને બાકાત રાખવા માટે સ્કોપને મર્યાદિત કરે છે, અથવા જો તેઓ સંપૂર્ણપણે પરવાનગી પાછી ખેંચી લે છે, તો પ્રથમ એન્ટ્રીને ઓવરરાઈટ કરશો નહીં. વર્ઝન ટુ લખો. વર્કરના હાથમાં રહેલી રિસીપ્ટ હજુ પણ વર્ઝન વન કહે છે, અને પોલિસી એન્જિન ચોક્કસપણે જોઈ શકે છે કે વર્ઝન વન દ્વારા શું મંજૂરી આપવામાં આવી હતી અને તે ચોક્કસ ટાઈમસ્ટેમ્પ પર બદલાઈ ગઈ હતી.
આ અપરિવર્તનશીલતા (immutability) એ તમારો ઓડિટનો મુખ્ય આધાર છે. છ મહિના પછી, જ્યારે કમ્પ્લાયન્સ ઓફિસર પૂછે કે કોઈ ચોક્કસ ETL જોબ ગુરુવારે બપોરે કેમ ચાલતી હતી, ત્યારે તમે તે જોબ સાથે જોડાયેલ ચોક્કસ ગ્રાન્ટ વર્ઝન શોધી શકો છો અને સાબિત કરી શકો છો કે જ્યારે જોબ શરૂ થઈ ત્યારે તે માન્ય હતી. જો તમે યુઝર પ્રોફાઇલમાં કન્સેન્ટને સિંગલ બુલિયન ફ્લેગ (boolean flag) તરીકે સંગ્રહિત કરો છો, તો તમે તે ઇતિહાસ ભૂંસી નાખો છો. તમે "આ ક્યારેય મંજૂર કરવામાં આવ્યું નહોતું" અને "જ્યારે જોબ શરૂ થઈ ત્યારે તે મંજૂર હતું પરંતુ વપરાશકર્તાએ બે કલાક પછી પોતાનો નિર્ણય બદલી નાખ્યો હતો" વચ્ચેનો તફાવત પારખવાની ક્ષમતા ગુમાવો છો.
પ્રમાણિકતા માટે એન્ડપોઇન્ટ્સ ડિઝાઇન કરો
કન્સેન્ટ API એ સ્પષ્ટ અને ચોક્કસ રૂટ્સ આપવા જોઈએ. POST /grants ને નવી પરવાનગી બનાવવા દો. GET /grants/{id} ને ચોક્કસ રિસીપ્ટની વર્તમાન સ્થિતિ પરત કરવા દો. POST /grants/{id}/revoke ને રિવોકેશન (પરવાનગી પાછી ખેંચવાની પ્રક્રિયા) શરૂ કરવા દો. એવું ન કરો કે રિવોક કરવાથી તમારા પાઇપલાઇન્સમાં ફ્લોટ કરતા હેલ્થ ડેટાની દરેક નકલ તરત જ ભૂંસી નાખવામાં આવે છે. તેના બદલે, 202 Accepted સ્ટેટસ સાથે રિવોકેશન ઓપરેશન ID પરત કરો. આ વપરાશકર્તાને જણાવે છે કે વિનંતી સાચી છે, તે શરૂ થઈ રહી છે, અને તેઓ તેને ટ્રેક કરી શકે છે.
જ્યારે વપરાશકર્તા ઇન્ટરફેસ ધીમો લાગવાને કારણે ડબલ-ક્લિક કરે છે ત્યારે તે ઓપરેશન ID નિર્ણાયક બની જાય છે. જો તેઓ બીજી રિવોકેશન વિનંતી સબમિટ કરે છે, તો મૂળ ઓપરેશન ID પરત કરો. અહીં આઈડેમપોટેન્સી (Idempotency) એ માત્ર એક વધારાની સુવિધા નથી; તે ડુપ્લીકેટ ગભરાટને અટકાવે છે અને વપરાશકર્તાને તેમની વિનંતીની સ્થિતિ માટે સિંગલ સોર્સ ઓફ ટ્રુથ (સત્યનો એકમાત્ર સ્ત્રોત) આપે છે.
શક્ય તેટલી છેલ્લી ક્ષણે પરવાનગી માંગો
એક સામાન્ય ભૂલ એ છે કે API ગેટવે પર કન્સેન્ટ તપાસવું અને પછી વર્કરની અંદર કેશ કરેલા ફ્લેગ (cached flag) પર વિશ્વાસ કરવો. આવું કરશો નહીં. વર્કરે તેની જોબ લાઈફસાયલક દરમિયાન તેની રિસીપ્ટ સાથે રાખવી જોઈએ. હેલ્થ રેકોર્ડ સ્ટોર સામે ક્વેરી એક્ઝિક્યુટ કરતા બરાબર પહેલા, તેણે પોલિસી લેયરને પૂછવું જોઈએ: “શું આ ચોક્કસ ગ્રાન્ટનું વર્ઝન ત્રણ હજુ પણ આ ચોક્કસ સ્કોપ માટે માન્ય છે?” જો જવાબ ના હોય, તો વર્કર અટકી જાય છે. તે જોબ ફેલ કરે છે. તે ફરીથી પ્રયાસ (retry) કરતું નથી.
અહીં રીટ્રાય લોજિક (retry logic) ઝેર સમાન છે. વર્ઝન મિસમેચ એ નેટવર્કની નાની સમસ્યા નથી. તે માનવીય નિર્ણય છે. વપરાશકર્તાએ પરવાનગી પાછી ખેંચી લીધી છે, અથવા ગ્રાન્ટની અવધિ પૂરી થઈ ગઈ છે, અથવા સ્કોપ ઘટી ગયો છે. જો તમે ત્રણ વાર પ્રયાસ કરો છો અને રેસ કન્ડિશન (race condition) ને કારણે ચોથી વાર સફળ થાઓ છો, તો તમે હમણાં જ કન્સેન્ટનું ઉલ્લંઘન કર્યું છે. મિસમેચને હાર્ડ ફેઈલ્યુર (hard failure) તરીકે ગણો, તેને તમારા ડેડ-લેટર ક્યુ (dead-letter queue) અથવા ઓપરેશન્સ ડેશબોર્ડ પર મોકલો, અને માનવીય તપાસ કરવા દો.
અસ્તવ્યસ્ત પરિસ્થિતિઓને સંભાળો
વાસ્તવિક સિસ્ટમો વ્યવસ્થિત તબક્કાઓમાં કામ કરતી નથી. વપરાશકર્તાઓ જૂના બ્રાઉઝર ટેબ્સ ખુલ્લા રાખે છે. બલ્ક ઇમ્પોર્ટ્સ (Bulk imports) વીસ મિનિટ સુધી ચાલે છે. સિંક (sync) અધવચ્ચે ચાલુ હોય ત્યારે સ્કોપ્સ (Scopes) બદલાઈ જાય છે. તમારી કન્સેન્ટ API ને આ ક્ષણો માટે સ્પષ્ટ નિયમોની જરૂર છે.
જૂના (Stale) બ્રાઉઝર ટેબ્સ. વપરાશકર્તા તાજેતરમાં ખોલેલા ટેબમાં એક્સેસ રદ કરે છે. એક જૂનું ટેબ, જે અગાઉના પેજ લોડમાંથી ગ્રાન્ટ ઓબ્જેક્ટ (grant object) ધરાવે છે, તે ફરીથી કનેક્ટ કરવાનો પ્રયાસ કરે છે. તમારા બેકએન્ડ (backend) એ તે જૂની રસીદ (stale receipt) ને તરત જ નકારી કાઢવી જોઈએ અને નવી કન્સેન્ટ રિવ્યુ (consent review) માટે મજબૂર કરવું જોઈએ. રદ કરેલી ગ્રાન્ટ રદ થયેલા પાસપોર્ટ જેવી હોવી જોઈએ: જો ધારકને ડ્રોઅરમાં જૂની નકલ મળી જાય તો પણ તે ફરીથી સક્રિય ન થવી જોઈએ.
ચાલુ (In-flight) ઇમ્પોર્ટ્સ. જો બલ્ક ઇમ્પોર્ટ ચાલુ હોય અને વપરાશકર્તા એક્સેસ રદ કરે, તો તમારે એકસાથે બે વસ્તુઓ કરવાની જરૂર છે. પ્રથમ, વર્ઝન રિજેક્ટ થાય તે ક્ષણે નવા ડેટા લખવાની (writes) મંજૂરી બંધ કરો. બીજું, ઓપરેશન ID દ્વારા વપરાશકર્તાને સાચી ક્લીનઅપ પ્રગતિ બતાવો. તેમને સત્યતાપૂર્ણ સ્ટેટસ પેજ આપો: “રદબાતલ કરવાની વિનંતી સ્વીકારવામાં આવી છે. અઢાર પેન્ડિંગ રાઈટ્સ (pending writes) દૂર કરવામાં આવી રહ્યા છે.” જે ગ્રાન્ટ વર્ઝનને પહેલેથી જ અમાન્ય (invalid) તરીકે ચિહ્નિત કરવામાં આવ્યું હોય, તેનો ઉપયોગ કરીને વર્કર્સને ડેટા કમિટ (commit) કરવા ન દો.
સ્કોપમાં ફેરફાર (Scope changes). ધારો કે વપરાશકર્તાએ મૂળરૂપે પાંચ વર્ષના ઇતિહાસ માટે એક્સેસ આપ્યો હતો અને પછી તેને છ મહિનામાં બદલી નાખ્યો. મૂળ ગ્રાન્ટમાં ફેરફાર કરશો નહીં. વર્ઝન વન બંધ કરો, સાંકડી સમયમર્યાદા સાથે વર્ઝન ટુ ઇશ્યૂ કરો, અને કોઈપણ ચાલુ પ્રક્રિયાઓને નવા સીમાડા મુજબ સુધારવા (reconcile) માટે મજબૂર કરો. જૂનું વર્ઝન તમારા લોગમાં ઐતિહાસિક તથ્ય તરીકે રહેવું જોઈએ, સક્રિય પરવાનગી તરીકે નહીં.
કડક સુરક્ષા નિયમો (Hard Security Rules)
રસીદો (Receipts) પોતે સંવેદનશીલ છે, પરંતુ તે ક્લિનિકલ ડેટા નથી. તેમને તમારા આર્કિટેક્ચરમાં અલગ રાખો. માત્ર દર્દી અથવા ખાસ રીતે સોંપવામાં આવેલી ભૂમિકા—જેમ કે કાયદેસરનો વાલી અથવા અધિકૃત સંભાળ રાખનાર—તે જ રસીદ જોઈ શકે અથવા રદ કરી શકે. આ નિયમ માત્ર UI રાઉટિંગ ટેબલમાં જ નહીં, પરંતુ ડેટા લેયરમાં (data layer) લાગુ કરો.
જ્યારે જોબ્સ (jobs) નિષ્ફળ જાય ત્યારે તમારા એરર લોગ્સ (error logs) હેલ્થ ડેટા મેળવવાનો પ્રયાસ કરશે. આ વૃત્તિનો આક્રમક રીતે વિરોધ કરો. જ્યારે કોઈ વર્કર અમાન્ય કન્સેન્ટ રસીદ રજૂ કરવાને કારણે અટકી જાય, ત્યારે ગ્રાન્ટ ID, વર્ઝન અને એરર લોગ કરો. દર્દીની ઓળખ (patient identifier), નિદાન કોડ (diagnosis code), અથવા લેબ વેલ્યુ (lab value) જે વર્કર મેળવવાનો પ્રયાસ કરી રહ્યો હતો, તેને ક્યારેય લોગ ન કરો. લોગ્સમાં હેલ્થ ડેટા ફૂગની જેમ ફેલાય છે: તે બેકઅપ લેવાય છે, ઇન્ડેક્સ કરવામાં આવે છે અને એવી રીતે ભૂલી જવાય છે જે તમારા સામાન્ય એક્સેસ કંટ્રોલ્સને બાયપાસ કરે છે.
અંતે, સિસ્ટમ રિકવરી દરમિયાન ક્યારેય જૂની સક્રિય ગ્રાન્ટને પુનઃસ્થાપિત (restore) કરશો નહીં. જો તમે ડેટાબેઝ રોલબેક કરો છો અથવા સ્નેપશોટ રિસ્ટોર કરો છો જેમાં ગ્રાન્ટ ટેબલનું રદ કરતા પહેલાનું વર્ઝન હોય, તો તમારી રનબુક (runbook) એ સર્વિસ નવો ટ્રાફિક સ્વીકારતા પહેલા તે પુનર્જીવિત પરવાનગીઓને આપમેળે અક્ષમ કરી દેવી જોઈએ. ઐતિહાસિક કન્સેન્ટ સ્ટેટ્સ ઓડિટ લોગમાં હોવા જોઈએ, સક્રિય નિયમ સેટમાં ક્યારેય નહીં.