ایک مریض "Disconnect My Data" نامی بٹن پر کلک کرتا ہے۔ ویب ایپ ایک سبز ٹک اور ایک خوش کن تصدیق دکھاتی ہے۔ بیک گراؤنڈ کیو میں کہیں، ایک ورکر پروسیس اپنی رات کی سنک (sync) کے لیے بیدار ہوتا ہے، کل بنایا گیا ایک کام (job) اٹھاتا ہے، اور دو سالہ ادویات کی ہسٹری کو ڈاؤن اسٹریم اینالیٹکس کلسٹر (downstream analytics cluster) کو بھیجنا شروع کر دیتا ہے۔ صارف نے انٹرفیس پر بھروسہ کیا۔ سسٹم نے اس بھروسے کو توڑ دیا۔
ناکامی کا یہ مخصوص طریقہ ہیلتھ ڈیٹا آرکیٹیکچر کے لیے ایک بڑا خطرہ ہے کیونکہ اس میں داؤ پر بہت کچھ لگا ہوتا ہے۔ ایک پرانی یا غیر متعلقہ اجازت (stale permission) کوئی معمولی بگ نہیں ہے؛ یہ ایک فعال ڈیٹا خلاف ورزی (active breach) ہے۔ اس کا حل ہر ڈیٹا کی درخواست کو ایک "رضامندی کی رسید" (consent receipt) سے جوڑنا ہے: ایک چھوٹا، منظم ریکارڈ جو صارف کے ارادے کو UI سے لے کر آپ کے پالیسی انجن، ڈیٹا بیس ٹرانزیکشنز، اور ہر بیک گراؤنڈ ورکر تک پہنچاتا ہے۔ یہ کبھی بھی کلینیکل ویلیوز کو اسٹور نہیں کرتا۔ یہ صرف ان تک رسائی کا حق اسٹور کرتا ہے، جس پر ایک ایسا ورژن لگا ہوتا ہے جو پس منظر میں خاموشی سے تبدیل نہیں ہو سکتا۔
رسید میں اصل میں کیا ہوتا ہے
رسید کو ایک اسکوپ شدہ معاہدے (scoped contract) کے طور پر سمجھیں، نہ کہ محض ایک سیشن فلیگ کے طور پر۔ اس میں ایک گرانٹ آئیڈنٹیفائر (grant identifier)، ڈیٹا سبجیکٹ، رسائی کا درست دائرہ کار (lab results، vitals، medication history)، وقت کی حد کے اندر درستگی کا دورانیہ، اور ایک ورژن نمبر شامل ہوتا ہے۔ جب فرنٹ اینڈ کسی صارف کی طرف سے رسائی کی درخواست کرتا ہے، تو API یہ رسید جاری کرتی ہے۔ فرنٹ اینڈ اسے اپنے پاس رکھتا ہے۔ ہر وہ ڈاؤن اسٹریم سروس جو ہیلتھ ڈیٹا پڑھنا چاہتی ہے، اسے ایک مرکزی پالیسی لیئر (central policy layer) کے سامنے یہ رسید پیش کرنی ہوگی اور ریکارڈ کھولنے سے پہلے واضح اجازت حاصل کرنی ہوگی۔
یہ اس لیے اہم ہے کیونکہ ہیلتھ سسٹم اکثر یوزر اکاؤنٹ ٹوکن کو رضامندی سمجھنے کی غلطی کرتے ہیں۔ ایک ٹوکن بتاتا ہے کہ آپ کون ہیں۔ ایک رسید بتاتی ہے کہ آپ کو اس وقت کیا کرنے کی اجازت ہے۔ اگر ان دونوں میں فرق آ جائے، تو رسید کی جیت ہونی چاہیے۔
ہر چیز کو ورژن کریں
اپنے کنسنٹ اسٹور کو ایک "اپینڈ-اونلی لاگ" (append-only log) کے طور پر بنائیں۔ جب کوئی صارف پہلی بار اپنے حفاظتی ریکارڈز (immunization records) تک رسائی دیتا ہے، تو وہ ورژن ون ہوتا ہے۔ اگر وہ بعد میں مخصوص فراہم کنندگان (providers) کو نکالنے کے لیے اسکوپ کو محدود کرتا ہے، یا اگر وہ مکمل طور پر اجازت واپس لے لیتا ہے، تو پہلی انٹری کو اوور رائٹ نہ کریں۔ ورژن ٹو لکھیں۔ ورکر کے ہاتھ میں موجود رسید اب بھی ورژن ون ہی کہے گی، اور پالیسی انجن دیکھ سکے گا کہ ورژن ون نے کیا اجازت دی تھی اور اسے ایک مخصوص ٹائم اسٹیمپ پر تبدیل کر دیا گیا تھا۔
یہ غیر تبدیلی (immutability) آپ کے آڈٹ کی بنیاد ہے۔ چھ ماہ بعد، جب کوئی کمپلائنس آفیسر پوچھے کہ ایک مخصوص ETL جاب جمعرات کی دوپہر کو کیوں چلی تھی، تو آپ اس جاب کے ذریعے بھیجی گئی گرانٹ کے درست ورژن کا سراغ لگا سکتے ہیں اور ثابت کر سکتے ہیں کہ جاب شروع ہوتے وقت وہ درست تھی۔ اگر آپ صارف کے پروفائل میں رضامندی کو محض ایک سنگل بوولین فلیگ (boolean flag) کے طور پر اسٹور کرتے ہیں، تو آپ وہ تاریخ مٹا دیتے ہیں۔ آپ "اس کی کبھی اجازت نہیں تھی" اور "جاب شروع ہوتے وقت اس کی اجازت تھی لیکن دو گھنٹے بعد صارف نے اپنا ارادہ بدل لیا" کے درمیان فرق کرنے کی صلاحیت کھو دیتے ہیں۔
ایمانداری کے لیے اینڈ پوائنٹس ڈیزائن کریں
ایک کنسنٹ API کو واضح اور مخصوص روٹس (routes) فراہم کرنے چاہئیں۔ POST /grants کو نئی اجازت بنانے دیں۔ GET /grants/{id} کو کسی مخصوص رسید کی موجودہ حالت واپس کرنے دیں۔ POST /grants/{id}/revoke کو اجازت کی واپسی کا عمل شروع کرنے دیں۔ یہ دکھاوا نہ کریں کہ ریووک (revoke) کرنے سے آپ کے پائپ لائنز میں موجود ہیلتھ ڈیٹا کی ہر کاپی فوری طور پر مٹ جاتی ہے۔ اس کے بجائے، 202 Accepted اسٹیٹس کے ساتھ ایک ریووکیشن آپریشن آئی ڈی (revocation operation ID) واپس کریں۔ یہ صارف کو بتاتا ہے کہ درخواست حقیقی ہے، یہ شروع ہو چکی ہے، اور وہ اسے ٹریک کر سکتے ہیں۔
وہ آپریشن آئی ڈی اس وقت اہم ہو جاتا ہے جب صارف انٹرفیس کے سست محسوس ہونے کی وجہ سے ڈبل کلک کر دیتا ہے۔ اگر وہ دوسری ریووکیشن درخواست جمع کرواتا ہے، تو اصل آپریشن آئی ڈی ہی واپس کریں۔ یہاں آئیڈیم پوٹینسی (idempotency) کوئی اضافی سہولت نہیں ہے؛ یہ ڈپلیکیٹ پریشانی کو روکتی ہے اور صارف کو ان کی درخواست کی صورتحال کے لیے معلومات کا ایک واحد ذریعہ (single source of truth) فراہم کرتی ہے۔
آخری ممکنہ لمحے پر اجازت مانگیں
ایک عام غلطی یہ ہے کہ API گیٹ وے پر رضامندی چیک کی جاتی ہے اور پھر ورکر کے اندر کسی کیشڈ فلیگ (cached flag) پر بھروسہ کیا جاتا ہے۔ ایسا نہ کریں۔ ورکر کو جاب لائف سائیکل کے دوران اپنی رسید ساتھ رکھنی چاہیے۔ ہیلتھ ریکارڈ اسٹور کے خلاف کوئری چلانے سے بالکل پہلے، اسے پالیسی لیئر سے پوچھنا چاہیے: "کیا اس مخصوص گرانٹ کا ورژن تین اب بھی اس درست اسکوپ کے لیے کارآمد ہے؟" اگر جواب نہیں ہے، تو ورکر رک جاتا ہے۔ وہ جاب کو فیل کر دیتا ہے۔ وہ اسے دوبارہ کرنے (retry) کی کوشش نہیں کرتا۔
یہاں ری ٹرائی لاجک (retry logic) زہر ہے۔ ورژن کا فرق (version mismatch) کوئی نیٹ ورک کی خرابی نہیں ہے۔ یہ ایک انسانی فیصلہ ہے۔ صارف نے اجازت واپس لے لی، یا گرانٹ کی مدت ختم ہو گئی، یا اسکوپ کم ہو گیا۔ اگر آپ تین بار کوشش کرتے ہیں اور چوتھی بار ریس کنڈیشن (race condition) کی وجہ سے کامیاب ہو جاتے ہیں، تو آپ نے ابھی ابھی رضامندی کی خلاف ورزی کی ہے۔ اس فرق کو ایک ہارڈ فیلئیر (hard failure) کے طور پر لیں، اسے اپنے ڈیڈ لیٹر کیو (dead-letter queue) یا آپریشنز ڈیش بورڈ پر بھیجیں، اور کسی انسان کو اس کی تحقیقات کرنے دیں۔
پیچیدہ صورتحال سے نمٹیں
Real systems do not move in tidy steps. Users leave old browser tabs open. Bulk imports run for twenty minutes. Scopes change while a sync is halfway done. Your consent API needs explicit rules for these moments.
Stale browser tabs. A user revokes access in a freshly opened tab. An older tab, still holding a grant object from a previous page load, tries to reconnect. Your backend must reject that stale receipt immediately and force a fresh consent review. A revoked grant should behave like a canceled passport: it does not come back to life because the holder found an old copy in a drawer.
In-flight imports. If a bulk import is running and the user revokes, you need two things to happen at once. First, stop allowing new writes the instant the version is rejected. Second, show the user real cleanup progress through the operation ID. Give them a truthful status page: “Revocation accepted. Eighteen pending writes are being purged.” Do not let workers commit data using a grant version that has already been marked invalid.
Scope changes. Suppose a user originally granted access to five years of history and later adjusts it to six months. Do not mutate the original grant. Close version one, issue version two with the narrower window, and force any ongoing processes to reconcile against the new boundary. The older version remains in your log as a historical fact, not as a living permission.
Hard Security Rules
Receipts themselves are sensitive, but they are not clinical data. Keep them separated in your architecture. Only the patient or a specifically delegated role—such as a legal guardian or an authorized caregiver—should be able to view or revoke a receipt. Enforce this at the data layer, not just in the UI routing table.
Your error logs will try to suck in health data when jobs fail. Fight this tendency aggressively. When a worker dies because it presented an invalid consent receipt, log the grant ID, the version, and the error. Never log the patient identifier, the diagnosis code, or the lab value that the worker was attempting to fetch. Health data in logs spreads like mold: it gets backed up, indexed, and forgotten in ways that bypass your normal access controls.
Finally, never restore an old active grant during a system recovery. If you roll back a database or restore a snapshot that happens to contain a pre-revocation version of a grant table, your runbook must automatically disable those resurrected permissions before the service accepts new traffic. Historical consent states belong in the audit log, never in the active rule set.