Bir hasta, “Verilerimin Bağlantısını Kes” etiketli bir düğmeye tıklar. Web uygulaması yeşil bir onay işareti ve neşeli bir onay mesajı gösterir. Arka plandaki bir kuyrukta, bir worker süreci gecelik senkronizasyonu için uyanır, dünden kalan bir işi çeker ve iki yıllık ilaç geçmişini bir downstream analiz kümesine aktarmaya başlar. Kullanıcı arayüze güvenmiştir. Sistem bu güvene ihanet etmiştir.
Bu spesifik hata modu, riskler çok yüksek olduğu için sağlık verisi mimarilerini kabusa çevirir. Geçersiz kalmış bir izin, küçük bir hata değildir; aktif bir ihlaldir. Çözüm, her bir veri talebini bir onay makbuzuna (consent receipt) bağlamaktır: Kullanıcının niyetini arayüzden alıp politika motorunuza, veritabanı işlemlerinize ve her bir arka plan worker'ına kadar taşıyan küçük, yapılandırılmış bir kayıt. Bu makbuz asla klinik değerleri saklamaz. Sadece onlara erişme hakkını saklar ve bu hak, perde arkasında sessizce değişemeyecek bir sürümle damgalanır.
Makbuz Aslında Neleri İçerir
Makbuzu bir oturum bayrağı (session flag) olarak değil, kapsamlı bir sözleşme olarak düşünün. Bir izin tanımlayıcı, veri sahibi, erişimin tam kapsamı (laboratuvar sonuçları, yaşamsal bulgular, ilaç geçmişi), zamana bağlı bir geçerlilik aralığı ve bir sürüm numarası içerir. Bir frontend bir kullanıcı adına erişim talep ettiğinde, API bu makbuzu düzenler. Frontend bunu elinde tutar. Sağlık verilerini okumak isteyen her bir downstream servis, kaydı açmadan önce makbuzu merkezi bir politika katmanına sunmalı ve açık bir onay almalıdır.
Bu konu önemlidir çünkü sağlık sistemleri genellikle bir kullanıcı hesabı token'ını, onay (consent) ile karıştırır. Bir token kim olduğunuzu söyler. Bir makbuz ise şu anda ne yapmaya yetkiniz olduğunu söyler. Eğer ikisi birbirinden ayrışırsa, her zaman makbuz üstün gelmelidir.
Her Şeyi Sürümleyin
Onay deponuzu, sadece eklemeye dayalı (append-only) bir günlük olarak inşa edin. Bir kullanıcı aşı kayıtlarına erişim izni verdiğinde, bu birinci sürümdür. Eğer daha sonra kapsamı belirli sağlayıcıları hariç tutacak şekilde daraltırsa veya izni tamamen iptal ederse, ilk girişi üzerine yazmayın. İkinci sürümü yazın. Worker'ın elindeki makbuz hala birinci sürümü gösteriyor olacaktır ve politika motoru, birinci sürümün tam olarak neye izin verdiğini ve belirli bir zaman damgasıyla geçersiz kılındığını görebilecektir.
Bu değişmezlik (immutability), denetim omurganızdır. Altı ay sonra bir uyumluluk görevlisi, belirli bir ETL işinin neden bir Perşembe öğleden sonra çalıştığını sorduğunda, işin taşıdığı tam izin sürümünü izleyebilir ve iş başladığında geçerli olduğunu kanıtlayabilirsiniz. Eğer onayı bir kullanıcı profilinde tek bir boolean bayrak olarak saklarsanız, bu geçmişi silmiş olursunuz. “Bu hiçbir zaman izinli değildi” ile “İş başladığında izinliydi ancak kullanıcı iki saat sonra fikrini değiştirdi” arasındaki farkı ayırt etme yeteneğinizi kaybedersiniz.
Dürüstlük İçin Uç Noktalar Tasarlayın
Bir onay API'si net ve spesifik rotalar sunmalıdır. POST /grants yeni bir izin oluşturmasına izin verin. GET /grants/{id} belirli bir makbuzun mevcut durumunu döndürsün. POST /grants/{id}/revoke bir iptal işlemini başlatsın. İptal et düğmesine basmanın, boru hatlarınızda (pipelines) dolaşan her bir sağlık verisi kopyasını anında sildiğini varsaymayın. Bunun yerine, bir 202 Accepted durumu ile bir iptal işlemi kimliği (operation ID) döndürün. Bu, kullanıcıya isteğin gerçek olduğunu, başladığını ve bunu takip edebileceğini söyler.
Arayüz yavaş hissettirdiği için kullanıcı düğmeye iki kez tıkladığında, o işlem kimliği kritik hale gelir. Eğer ikinci bir iptal isteği gönderirse, orijinal işlem kimliğini döndürün. Buradaki Idempotency bir lüks değil; gereksiz paniği önler ve kullanıcıya isteğinin durumu için tek bir doğruluk kaynağı sağlar.
İzni Mümkün Olan En Son Anda İsteyin
Yaygın bir hata, onayı API ağ geçidinde (gateway) kontrol edip ardından bir worker'ın derinliklerindeki önbelleğe alınmış bir bayrağa güvenmektir. Bunu yapmayın. Worker, makbuzunu iş yaşam döngüsü boyunca yanında taşımalıdır. Sağlık kaydı deposuna yönelik sorguyu yürütmeden hemen önce politika katmanına sormalıdır: “Bu spesifik iznin üçüncü sürümü, tam olarak bu kapsam için hala geçerli mi?” Cevap hayır ise, worker durur. İşi başarısız sayar. Yeniden denemez.
Burada yeniden deneme (retry) mantığı zehirlidir. Bir sürüm uyuşmazlığı bir ağ dalgalanması değildir. Bu insani bir karardır. Kullanıcı izni iptal etmiştir, izin süresi dolmuştur veya kapsam daralmıştır. Eğer üç kez yeniden dener ve bir yarış durumu (race condition) nedeniyle dördüncüde başarılı olursanız, onayı ihlal etmiş olursunuz. Uyuşmazlığı sert bir hata (hard failure) olarak ele alın, bunu dead-letter kuyruğunuza veya operasyon panelinize iletin ve bir insanın incelemesine izin verin.
Karmaşık Senaryoları Yönetin
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.