ఒక రోగి “Disconnect My Data” అనే బటన్ను క్లిక్ చేస్తారు. వెబ్ యాప్ ఒక గ్రీన్ చెక్మార్క్ను మరియు సంతోషకరమైన నిర్ధారణ సందేశాన్ని చూపిస్తుంది. కానీ బ్యాక్గ్రౌండ్ క్యూలో, ఒక వర్కర్ ప్రాసెస్ తన నైట్లీ సింక్ (nightly sync) కోసం మేల్కొంటుంది, నిన్న సృష్టించబడిన ఒక జాబ్ను తీసుకుంటుంది మరియు రెండు సంవత్సరాల మందుల చరిత్రను (medication history) డౌన్స్ట్రీమ్ అనలిటిక్స్ క్లస్టర్కు స్ట్రీమ్ చేయడం ప్రారంభిస్తుంది. వినియోగదారు ఇంటర్ఫేస్ను నమ్మారు. కానీ సిస్టమ్ ఆ నమ్మకాన్ని వమ్ము చేసింది.
ఈ నిర్దిష్ట వైఫల్య విధానం (failure mode) హెల్త్ డేటా ఆర్కిటెక్చర్లో చాలా ప్రమాదకరమైనది, ఎందుకంటే ఇక్కడ రిస్క్ చాలా ఎక్కువగా ఉంటుంది. పాతబడిన అనుమతి (stale permission) అనేది చిన్న బగ్ కాదు; అది ఒక యాక్టివ్ బ్రీచ్ (active breach). దీనికి పరిష్కారం ఏమిటంటే, ప్రతి డేటా రిక్వెస్ట్ను ఒక consent receiptకి అనుసంధానించడం: ఇది ఒక చిన్న, నిర్మాణాత్మక రికార్డ్, ఇది వినియోగదారు యొక్క ఉద్దేశాన్ని UI నుండి మీ పాలసీ ఇంజిన్, మీ డేటాబేస్ ట్రాన్సాక్షన్లు మరియు ప్రతి బ్యాక్గ్రౌండ్ వర్కర్కు తీసుకెళ్తుంది. ఇది క్లినికల్ విలువలను (clinical values) ఎప్పుడూ నిల్వ చేయదు. ఇది కేవలం వాటిని యాక్సెస్ చేసే హక్కును మాత్రమే నిల్వ చేస్తుంది, మరియు ఆ హక్కు వెనుక తెరపై మారుతూ ఉండలేని ఒక వెర్షన్తో ముద్రించబడి ఉంటుంది.
ఆ రసీదు (Receipt) నిజంగా ఏమి కలిగి ఉంటుంది
రసీదును ఒక సెషన్ ఫ్లాగ్ (session flag) లాగా కాకుండా, ఒక స్కోప్డ్ కాంట్రాక్ట్ (scoped contract) లాగా భావించండి. ఇందులో గ్రాంట్ ఐడెంటిఫైయర్ (grant identifier), డేటా సబ్జెక్ట్, యాక్సెస్ యొక్క ఖచ్చితమైన స్కోప్ (lab results, vitals, medication history), సమయ పరిమితి కలిగిన వాలిడిటీ విండో మరియు వెర్షన్ నంబర్ ఉంటాయి. ఫ్రంటెండ్ ఒక వినియోగదారు తరపున యాక్సెస్ను కోరినప్పుడు, API ఈ రసీదును జారీ చేస్తుంది. ఫ్రంటెండ్ దానిని కలిగి ఉంటుంది. హెల్త్ డేటాను చదవాలనుకునే ప్రతి డౌన్స్ట్రీమ్ సర్వీస్, రికార్డ్ను తెరవడానికి ముందు ఒక సెంట్రల్ పాలసీ లేయర్కు ఈ రసీదును సమర్పించి, స్పష్టమైన అనుమతిని పొందాలి.
ఇది ఎందుకు ముఖ్యమంటే, హెల్త్ సిస్టమ్స్ తరచుగా యూజర్ అకౌంట్ టోకెన్ను (user account token) సమ్మతి (consent) అని పొరబడతాయి. టోకెన్ మీరు ఎవరో చెబుతుంది. రసీదు మీరు ప్రస్తుతం ఏమి చేయవచ్చో చెబుతుంది. ఈ రెండింటి మధ్య తేడా వస్తే, ఎల్లప్పుడూ రసీదుకే ప్రాధాన్యత ఉండాలి.
ప్రతిదీ వెర్షనింగ్ చేయండి (Version Everything)
మీ కన్సెంట్ స్టోర్ను ఒక append-only log గా నిర్మించండి. వినియోగదారు మొదట వారి ఇమ్యునైజేషన్ రికార్డులకు యాక్సెస్ ఇచ్చినప్పుడు, అది వెర్షన్ వన్. ఒకవేళ వారు తర్వాత నిర్దిష్ట ప్రొవైడర్లను మినహాయించేలా స్కోప్ను తగ్గించినా, లేదా పూర్తిగా రద్దు చేసినా, మొదటి ఎంట్రీని ఓవర్రైట్ చేయవద్దు. వెర్షన్ టూను రాయండి. వర్కర్ చేతిలో ఉన్న రసీదు ఇంకా వెర్షన్ వన్ అని చూపుతుంది, మరియు పాలసీ ఇంజిన్ వెర్షన్ వన్ ఏమి అనుమతించిందో మరియు అది ఒక నిర్దిష్ట టైమ్స్టాంప్లో భర్తీ చేయబడిందని ఖచ్చితంగా చూడగలదు.
ఈ ఇమ్యుటబిలిటీ (immutability) మీ ఆడిట్ బ్యాక్బోన్. ఆరు నెలల తర్వాత, ఒక కంప్లయన్స్ ఆఫీసర్ ఒక నిర్దిష్ట ETL జాబ్ గురువారం మధ్యాహ్నం ఎందుకు రన్ అయిందో అని అడిగినప్పుడు, ఆ జాబ్ ఏ గ్రాంట్ వెర్షన్ను కలిగి ఉందో మీరు గుర్తించగలరు మరియు జాబ్ ప్రారంభించినప్పుడు అది చెల్లుబాటు అయ్యిందని నిరూపించగలరు. మీరు కన్సెంట్ను యూజర్ ప్రొఫైల్లో ఒక సింగిల్ బూలియన్ ఫ్లాగ్ (boolean flag)గా నిల్వ చేస్తే, మీరు ఆ చరిత్రను తుడిచివేస్తారు. "ఇది ఎప్పుడూ అనుమతించబడలేదు" మరియు "జాబ్ ప్రారంభించినప్పుడు ఇది అనుమతించబడింది కానీ రెండు గంటల తర్వాత వినియోగదారు తన నిర్ణయాన్ని మార్చుకున్నారు" అనే రెండింటి మధ్య తేడాను గుర్తించే సామర్థ్యాన్ని మీరు కోల్పోతారు.
నిజాయితీ కోసం ఎండ్పాయింట్లను డిజైన్ చేయండి
కన్సెంట్ API స్పష్టమైన, నిర్దిష్టమైన రూట్లను (routes) కలిగి ఉండాలి. POST /grants కొత్త అనుమతిని సృష్టించడానికి అనుమతించండి. GET /grants/{id} ఒక నిర్దిష్ట రసీదు యొక్క ప్రస్తుత స్థితిని తిరిగి ఇచ్చేలా చూడండి. POST /grants/{id}/revoke రద్దు ప్రక్రియను ప్రారంభించడానికి అనుమతించండి. మీ పైప్లైన్లలో ఉన్న ప్రతి హెల్త్ డేటా కాపీని రద్దు (revoke) చేయడం వల్ల వెంటనే తుడిచివేసేయబడుతుందని భ్రమపడకండి. బదులుగా, 202 Accepted స్టేటస్తో ఒక రికవకేషన్ ఆపరేషన్ IDని తిరిగి ఇవ్వండి. ఇది రిక్వెస్ట్ నిజమైనదని, అది ప్రారంభమైందని మరియు వినియోగదారు దానిని ట్రాక్ చేయవచ్చని తెలియజేస్తుంది.
ఇంటర్ఫేస్ నెమ్మదిగా ఉన్నట్లు అనిపించి వినియోగదారు రెండుసార్లు క్లిక్ చేసినప్పుడు ఆ ఆపరేషన్ ID చాలా కీలకం అవుతుంది. ఒకవేళ వారు రెండవ రికవకేషన్ రిక్వెస్ట్ను సమర్పించినట్లయితే, అసలు ఆపరేషన్ IDనే తిరిగి ఇవ్వండి. ఇక్కడ Idempotency అనేది కేవలం ఒక అదనపు ఫీచర్ కాదు; ఇది డూప్లికేట్ పానిక్ను నివారిస్తుంది మరియు వినియోగదారు యొక్క రిక్వెస్ట్ స్థితికి ఒకే ఒక నిజమైన మూలాన్ని (single source of truth) అందిస్తుంది.
చివరి సాధ్యమైన క్షణంలోనే అనుమతి అడగండి
API గేట్వే వద్ద కన్సెంట్ను తనిఖీ చేసి, ఆపై వర్కర్ లోపల క్యాష్ చేయబడిన ఫ్లాగ్ను (cached flag) నమ్మడం అనేది ఒక సాధారణ తప్పు. ఇలా చేయకండి. వర్కర్ తన జాబ్ లైఫ్సైకిల్ అంతటా తన రసీదును కలిగి ఉండాలి. హెల్త్ రికార్డ్ స్టోర్పై క్వెరీని అమలు చేయడానికి సరిగ్గా ముందు, అది పాలసీ లేయర్ను అడగాలి: “ఈ నిర్దిష్ట గ్రాంట్ యొక్క వెర్షన్ మూడు ఇంకా ఈ ఖచ్చితమైన స్కోప్కు చెల్లుబాటు అవుతుందా?” సమాధానం 'కాదు' అయితే, వర్కర్ ఆగిపోతుంది. అది జాబ్ను ఫెయిల్ చేస్తుంది. అది మళ్ళీ ప్రయత్నించదు (retry చేయదు).
ఇక్కడ రిట్రై లాజిక్ (retry logic) విషంతో సమానం. వెర్షన్ మిస్మ్యాచ్ అనేది నెట్వర్క్ సమస్య కాదు. అది ఒక మానవ నిర్ణయం. వినియోగదారు రద్దు చేశారు, లేదా గ్రాంట్ గడువు ముగిసింది, లేదా స్కోప్ తగ్గింది. మీరు మూడుసార్లు ప్రయత్నించి, race condition వల్ల నాలుగవసారి విజయవంతమైతే, మీరు కన్సెంట్ను ఉల్లంఘించినట్లే. మిస్మ్యాచ్ను ఒక హార్డ్ ఫెయిల్యూర్ (hard failure)గా పరిగణించండి, దానిని మీ dead-letter queue లేదా ఆపరేషన్స్ డ్యాష్బోర్డ్కు పంపండి మరియు ఒక మనిషి దానిని పరిశోధించేలా చేయండి.
చిక్కులతో కూడిన పరిస్థితులను (Messy Scenarios) నిర్వహించండి
నిజమైన వ్యవస్థలు క్రమబద్ధమైన దశల్లో సాగవు. వినియోగదారులు పాత బ్రౌజర్ ట్యాబ్లను తెరిచి ఉంచుతారు. బల్క్ ఇంపోర్ట్లు (Bulk imports) ఇరవై నిమిషాల పాటు నడుస్తాయి. సింక్ (sync) సగం పూర్తయిన సమయంలో స్కోప్లు (Scopes) మారుతుంటాయి. ఇటువంటి సందర్భాల కోసం మీ కన్సెంట్ API (consent API) కి స్పష్టమైన నియమాలు అవసరం.
పాతబడిన బ్రౌజర్ ట్యాబ్లు (Stale browser tabs). వినియోగదారుడు కొత్తగా తెరిచిన ట్యాబ్లో యాక్సెస్ను ఉపసంహరించుకుంటారు (revokes). అంతకుముందు పేజీ లోడ్ అయినప్పుడు వచ్చిన గ్రాంట్ ఆబ్జెక్ట్ను (grant object) ఇంకా కలిగి ఉన్న పాత ట్యాబ్, తిరిగి కనెక్ట్ అవ్వడానికి ప్రయత్నిస్తుంది. మీ బ్యాకెండ్ ఆ పాత రిసీప్ట్ను వెంటనే తిరస్కరించి, కొత్త కన్సెంట్ రివ్యూను తప్పనిసరి చేయాలి. ఉపసంహరించబడిన గ్రాంట్ అనేది రద్దు చేయబడిన పాస్పోర్ట్ లాగా ఉండాలి: దాని యజమాని డ్రాయర్లో పాత కాపీని కనుగొన్నంత మాత్రాన అది మళ్ళీ ప్రాణం పోసుకుని పని చేయదు.
ప్రస్తుతం జరుగుతున్న ఇంపోర్ట్లు (In-flight imports). ఒక బల్క్ ఇంపోర్ట్ జరుగుతున్నప్పుడు వినియోగదారుడు యాక్సెస్ను ఉపసంహరించుకుంటే, రెండు పనులు ఒకేసారి జరగాలి. మొదటిది, వెర్షన్ తిరస్కరించబడిన వెంటనే కొత్త రైట్లను (writes) అనుమతించడాన్ని ఆపివేయాలి. రెండవది, ఆపరేషన్ ID ద్వారా క్లీనప్ ప్రక్రియ ఎంతవరకు వచ్చిందో వినియోగదారునికి చూపించాలి. వారికి నిజమైన స్టేటస్ పేజీని అందించండి: “ఉపసంహరణ ఆమోదించబడింది. పద్దెనిమిది పెండింగ్లో ఉన్న రైట్లు తొలగించబడుతున్నాయి (purged).” ఇప్పటికే చెల్లనిదిగా గుర్తించబడిన గ్రాంట్ వెర్షన్ను ఉపయోగించి వర్కర్లు డేటాను కమిట్ (commit) చేయనివ్వకండి.
స్కోప్ మార్పులు (Scope changes). ఒక వినియోగదారుడు మొదట ఐదేళ్ల చరిత్రకు యాక్సెస్ ఇచ్చి, తర్వాత దానిని ఆరు నెలలకు తగ్గించారనుకుందాం. అసలు గ్రాంట్ను మార్చకండి (mutate). వెర్షన్ 1ని మూసివేసి, తక్కువ కాలపరిమితితో వెర్షన్ 2ని జారీ చేయండి, మరియు ప్రస్తుతం జరుగుతున్న ఏ ప్రక్రియలనైనా కొత్త పరిమితులకు అనుగుణంగా సర్దుబాటు (reconcile) చేయమని ఆదేశించండి. పాత వెర్షన్ మీ లాగ్లో ఒక చారిత్రక వాస్తవంగా మాత్రమే ఉండాలి, అది ప్రస్తుతం అమలులో ఉన్న అనుమతిగా ఉండకూడదు.
కఠినమైన భద్రతా నియమాలు (Hard Security Rules)
రిసీప్ట్లు స్వయంగా సున్నితమైనవి, కానీ అవి క్లినికల్ డేటా (clinical data) కావు. మీ ఆర్కిటెక్చర్లో వాటిని వేరుగా ఉంచండి. రోగి లేదా ప్రత్యేకంగా అప్పగించబడిన పాత్ర—అంటే చట్టపరమైన సంరక్షకుడు (legal guardian) లేదా అధీకృత కేర్ గివర్ (authorized caregiver)—మాత్రమే రిసీప్ట్ను చూడగలగాలి లేదా ఉపసంహరించుకోగలగాలి. దీనిని కేవలం UI రూటింగ్ టేబుల్లో మాత్రమే కాకుండా, డేటా లేయర్లో (data layer) అమలు చేయండి.
జాబ్స్ విఫలమైనప్పుడు మీ ఎర్రర్ లాగ్లు (error logs) ఆరోగ్య డేటాను (health data) కూడా లోపలికి లాగేయడానికి ప్రయత్నిస్తాయి. ఈ ధోరణిని బలంగా అడ్డుకోండి. ఒక వర్కర్ చెల్లని కన్సెంట్ రిసీప్ట్ను సమర్పించినందున విఫలమైనప్పుడు, గ్రాంట్ ID, వెర్షన్ మరియు ఎర్రర్ను మాత్రమే లాగ్ చేయండి. వర్కర్ సేకరించడానికి ప్రయత్నిస్తున్న రోగి గుర్తింపు (patient identifier), డయాగ్నోసిస్ కోడ్ (diagnosis code) లేదా ల్యాబ్ విలువను (lab value) ఎప్పుడూ లాగ్ చేయకండి. లాగ్లలో ఉండే ఆరోగ్య డేటా బూజులా వ్యాపిస్తుంది: అది బ్యాకప్ చేయబడుతుంది, ఇండెక్స్ చేయబడుతుంది మరియు మీ సాధారణ యాక్సెస్ కంట్రోల్లను దాటి మర్చిపోబడే అవకాశం ఉంటుంది.
చివరగా, సిస్టమ్ రికవరీ సమయంలో పాత యాక్టివ్ గ్రాంట్ను ఎప్పుడూ పునరుద్ధరించకండి (restore). మీరు డేటాబేస్ను రోల్ బ్యాక్ చేసినా లేదా గ్రాంట్ టేబుల్లోని ఉపసంహరణకు ముందున్న వెర్షన్ను కలిగి ఉన్న స్నాప్షాట్ను పునరుద్ధరించినా, సర్వీస్ కొత్త ట్రాఫిక్ను స్వీకరించకముందే మీ రన్బుక్ (runbook) ఆ పునరుద్ధరించబడిన అనుమతులను ఆటోమేటిక్గా నిలిపివేయాలి. చారిత్రక కన్సెంట్ స్టేట్లు (Historical consent states) ఆడిట్ లాగ్లో మాత్రమే ఉండాలి, యాక్టివ్ రూల్ సెట్లో ఉండకూడదు.