Eyni ID çarpaz tipli resurslar üçün FHIR versiyalaşdırma düzəlişi

9–11 aprel 2026 aralığında Azure Health Data Services FHIR service bəzi regionlarda platforma səviyyəli bir problem yaşayıb. Rəsmi simptom belə təsvir olunur: fərqli resource type-lar eyni resource ID-ni paylaşanda read və ya update əməliyyatları səhv verə bilərdi və ən son versiya düzgün qaytarılmaya bilərdi. Microsoft problemi 11 apreldə string-based ID müqayisəsini düzgün ResourceKey müqayisəsi ilə əvəz etməklə düzəldib. Bu hotfix izləri 11 aprel merge olunmuş PR-də, 17 apreldə çıxan 4.0.728 release-də və 30 aprel tarixli Learn release notes-da görünür. 

İcra xülasəsi

Bu problem sadəcə “kiçik bug” deyildi. O, idarə olunan bir API platformasında ən həssas məqamlardan birinə toxunurdu: sistem hansı resursu “current version” hesab edir. Microsoft-un aprel release note-u deyir ki, fərqli resource type-lar eyni resource ID istifadə edəndə access və ya update xətaları baş verə bilərdi və ən son versiya gözlənildiyi kimi qaytarılmaya bilərdi. PR və release trail isə texniki səbəbi daha açıq göstərir: SQL data store bəzi resursları “full history mode” vəziyyətinə sala bilirdi, yəni ən yüksək versiya tarixi versiya kimi işarələnir və aktiv versiya qalmırdı. 

Mühəndislik baxımından bunun mənası budur ki, adi read əməliyyatı yoxa çıxmış resurs kimi görünə bilər, adi update isə version-collision probleminə çevrilə bilər. Microsoft-un PR qeydlərində açıq şəkildə məqaləlıb ki, pozulmuş vəziyyətdə normal sorğular HTTP 404 verə bilər və update əməliyyatları mövcud resurs/type/version kombinasiya məhdudiyyəti ilə toqquşa bilər. 

Fon

Azure Health Data Services FHIR service idarə olunan PaaS FHIR endpoint-dir; REST API, RBAC və audit logging təqdim edir. Burada versioning modeli kritikdir, çünki history sistemin əsas funksiyalarından biridir. Microsoft-un versioning sənədi göstərir ki, default siyasət versioned-dur, yəni tarixçə saxlanılır və meta.versionId artırılır. Eyni sənəd history-nin resource, type və ya system səviyyəsində sorğulana bildiyini deyir. Məhz buna görə aktiv versiya ilə tarixi versiya arasındakı klassifikasiya səhvi əməliyyat baxımından ciddi problemə çevrilir. 

Bu mövzu xüsusilə healthcare və tənzimlənən workload-lar üçün vacibdir. Belə mühitlərdə data correctness, auditability və deterministik read davranışı “olsa yaxşıdır” səviyyəsində deyil. Bunlar əsas xidmət müqaviləsinin tərkib hissəsidir. FHIR service overview və logging sənədləri də bunu açıq şəkildə vurğulayır. 

Ətraflı izah

Microsoft-un aprel release note-u problemi və fix-i qısa şəkildə xülasə edir: fərqli resource type-lar eyni resource ID-ni paylaşanda versioning xətası yarana bilərdi və fix string-based müqayisəni düzgün ResourceKey müqayisəsi ilə əvəz etdi. 11 apreldə merge olunan PR isə root cause-u daha dərin izah edir: SQL data store resursu elə vəziyyətə sala bilərdi ki, ən yüksək versiya IsHistory: true kimi qalırdı və nəticədə resursun aktiv versiyası tam itirdi. 

Həmin PR failure mode-u da konkret şəkildə məqalər. Birincisi, resurslar update oluna bilmirdi, çünki servis resource type, resource ID və version 1 kombinasiyasını yenidən yaratmağa çalışır və mövcud constraint-lə toqquşurdu. İkincisi, aktiv versiya qalmadığı üçün normal sorğular HTTP 404 qaytara bilirdi; yalnız tarixi versiya birbaşa soruşulanda nəticə almaq olurdu. PR iki tipik ssenarini də göstərir: import əməliyyatları və eyni ID-ni paylaşan fərqli type resursları olan parallel bundle-lar. 

Aşağıdakı sadə flow problemin məntiqini göstərir. 

Rəsmi simptom və PR məzmununa əsaslanan minimal lab-repro belə düşünülə bilər:

PUT https://<fhir-service>/Patient/123
Content-Type: application/fhir+json

{
  "resourceType": "Patient",
  "id": "123",
  "active": true
}

PUT https://<fhir-service>/Observation/123
Content-Type: application/fhir+json

{
  "resourceType": "Observation",
  "id": "123",
  "status": "final",
  "subject": { "reference": "Patient/123" }
}

GET https://<fhir-service>/Patient/123
GET https://<fhir-service>/Observation/123
GET https://<fhir-service>/Patient/123/_history

Fix-dən əvvəl Microsoft deyir ki, “most recent version” düzgün qaytarılmaya bilərdi, PR isə belə hallarda normal read-in HTTP 404 verə biləcəyini bildirir. Update tərəfdə tam müştəriyə görünən exception mətni ictimai sənədlərdə dərc edilməyib, ona görə onu unspecified kimi qiymətləndirmək daha doğrudur. Sənədləşdirilən hissə odur ki, problem aktiv versiyanın itməsi ilə bağlı idi. 

Timeline baxımından sübut zənciri güclüdür. PR 11 aprel 2026 tarixində merge olunub. 4.0.728 release qeydləri 9–11 aprel impact window-u və “Fix data store key comparison” dəyişikliklərini açıq göstərir. Daha sonra Learn release notes eyni bug/fix-i aprel 2026 aylıq release hissəsində xülasə edir. 

Əməliyyat telemetriyası üçün Microsoft tövsiyə edir ki, diagnostic settings aktiv edilsin və log-lar Log Analytics, storage, Event Hubs və ya partner həllinə göndərilsin. Audit log sxemində CorrelationId, OperationName, RequestUri, FhirResourceType, StatusCode, ResultType kimi sahələr var və Microsoft MicrosoftHealthcareApisAuditLogs | where ResultType == "Failed" kimi sadə KQL nümunələri təqdim edir. 

Post-incident yoxlama üçün yığcam KQL nümunəsi:

MicrosoftHealthcareApisAuditLogs
| where ResultType == "Failed"
| where TimeGenerated > ago(7d)
| project TimeGenerated, CorrelationId, OperationName, FhirResourceType, RequestUri, StatusCode
| order by TimeGenerated desc

Microsoft-un sample audit log strukturuna uyğun redact olunmuş nümunə belə görünə bilər:

{
  "time": "2026-04-10T14:22:31Z",
  "operationName": "Microsoft.HealthcareApis/services/fhir-R4/update",
  "category": "AuditLogs",
  "resultType": "Failed",
  "statusCode": 404,
  "correlationId": "9f6a2c2d-<redacted>",
  "uri": "https://<workspace>-<service>.fhir.azurehealthcareapis.com/Patient/123",
  "properties": {
    "fhirResourceType": "Patient"
  }
}

Bir əlavə detal da vacibdir. PR mətninə görə Microsoft-un planı həm yeni problemlərin qarşısını alan hotfix-i, həm də artıq zədələnmiş resurslarda “aktiv versiyanı” yenidən aktivləşdirəcək növbəti addımı əhatə edirdi. Amma ictimai release note-lar əvvəllər zədələnmiş sətirlər üçün müştəriyə görünən tam remediation axınını təsvir etmir. Ona görə də 9–11 aprel intervalında problem görmüş tenant-lar üçün belə hallar support case kimi dəyərləndirilməlidir. 

Təsir qiymətləndirilməsi

Bu problemin təsiri yalnız availability ilə bitmir; əsas məsələ correctness-dir. Əgər yanlış versiya “history” kimi işarələnirsə, servis mövcud resursu sanki yox olmuş kimi göstərə bilər və ya tamamilə legitim update əməliyyatını rədd edə bilər. Downstream processing, research pipeline və ya provider-facing tətbiqlər üçün bu cür davranış ciddi insident sayılır. 

Fix-in strateji əhəmiyyəti də bundadır: resurs identikliyi yalnız string ID ilə deyil, resource type + ID birlikdə düşünülməlidir. FHIR modelində fərqli resource type-ların eyni resource ID-ni paylaşması legitimdir. Microsoft-un dərc etdiyi fix də məhz bunu təsdiqləyir — müqayisə ResourceKey səviyyəsinə keçirilib. 

Mitigasiya və best practice-lər

Əgər siz Azure üzərində FHIR workload işlədinizsə, ilk praktik qayda failed read və update əməliyyatlarını correlation ID ilə birlikdə izləməkdir. Audit log sxemi bunu rahat edir. İdxal əməliyyatlarından və ya yüksək paralelliyə malik bundle-lardan sonra sporadik 404 və ya update anomaliyaları görürsünüzsə, problemi yalnız tətbiq səviyyəsində axtarmayın; service audit loglarını resource type və URI kəsimində yoxlayın. 

İkinci qayda odur ki, integration suite daxilində eyni resource ID ilə fərqli resource type-ları qəsdən test edin. Bu “qəribə edge case” deyil; FHIR üçün tam keçərli formadır və Microsoft-un öz fix-i belə ssenarinin test olunmalı olduğunu göstərir. Məsələn, Patient/123 və Observation/123 üzərində update və history yoxlaması olan kiçik CI testi yaxşı geriyəqayıtma qorumasıdır. Bu tövsiyə Microsoft-un dərc etdiyi bug təsviri və PR qeydlərinə əsaslanan mühəndislik nəticəsidir. 

Üçüncü qayda: şübhəli resursları araşdıranda yalnız sadə GET-lə kifayətlənməyin. _history endpoint-lərindən istifadə edin və aktiv versioning policy-ni nəzərə alın. Microsoft-un history və versioning sənədləri göstərir ki, resursun zaman üzrə təkamülünü anlamağın düzgün yolu budur.