سرحد پار EHR انٹیگریشن سے حاصل ہونے والے 5 اسباق
میں نے دو مختلف ممالک کے درمیان مریضوں کے ریکارڈ کو جوڑنے میں مہینوں گزارے۔ میں نے دس سالہ کلینیکل تجربے رکھنے والی ایک لیڈ بزنس اینالسٹ (Lead Business Analyst) کے ساتھ کام کیا۔ ان کے انداز نے ہیلتھ کیئر سافٹ ویئر کے بارے میں میرا نظریہ بدل دیا۔
اس پروجیکٹ سے حاصل ہونے والے پانچ اسباق درج ذیل ہیں۔
- ٹرمینالوجی میپنگ (Terminology mapping)، ڈیٹا میپنگ سے زیادہ مشکل ہے
انجینئرز اکثر انٹیگریشن کو ایک اسکیمہ (schema) کے مسئلے کے طور پر دیکھتے ہیں۔ آپ فیلڈ A کو فیلڈ B سے جوڑتے ہیں اور کام ختم کر دیتے ہیں۔ ہیلتھ کیئر میں، یہ طریقہ ناکام ہو جاتا ہے۔
ایک سسٹم ICD-10 استعمال کر رہا تھا اور دوسرا ICD-11۔ ان کا آپس میں براہ راست ملاپ ممکن نہیں تھا۔ ایک سسٹم لیبز کے لیے LOINC استعمال کر رہا تھا جبکہ دوسرا پرانے اندرونی کوڈز استعمال کر رہا تھا۔
ہماری BA نے کوڈ لکھنے سے پہلے ایک 'کانسیپٹ کراس واک' (concept crosswalk) تیار کیا۔ انہوں نے مقامی کوڈز کو SNOMED CT جیسے معیاری سیٹ کے ساتھ میپ کیا۔ اس کے بغیر، ہم کلینیکل مفہوم کو بگاڑ سکتے تھے۔
غلط فیلڈ میپنگ غلط ویلیوز پیدا کرتی ہے۔ لیکن ٹرمینالوجی کی غلط میپنگ ایسی ویلیوز پیدا کرتی ہے جو دیکھنے میں درست لگتی ہیں لیکن کلینیکلی غلط ہوتی ہیں۔ دوسری صورتحال کہیں زیادہ خطرناک ہے۔
- ڈیٹا قوانین شروع میں ہی آرکیٹیکچر کی تشکیل کرتے ہیں
میں نے سوچا تھا کہ ہم پہلے ڈیٹا ماڈل ڈیزائن کریں گے اور تعمیل (compliance) کا معاملہ بعد میں دیکھیں گے۔ میں غلط تھا۔
سرحد پار جانے والا مریضوں کا ڈیٹا HIPAA یا GDPR جیسے متعدد قوانین کے دائرے میں آتا ہے۔ کچھ ممالک صحت کے ڈیٹا کو اپنی سرحدوں سے باہر لے جانے سے منع کرتے ہیں۔
ہماری BA نے شروع میں ہی قانونی ٹیموں کے ساتھ کام کیا۔ انہوں نے فیصلہ کیا کہ کون سی فیلڈز کو ریپلیکیٹ کیا جا سکتا ہے اور کن کے لیے 'ڈی آئیڈنٹی فیکیشن' (de-identification) ضروری ہے۔
اس نے ہمارے آرکیٹیکچر کو بدل دیا۔ ہم نے ایک سنگل ریپلیکیٹڈ ڈیٹا بیس کے بجائے ایک فیڈریٹڈ کوئری لیئر (federated query layer) بنائی۔ ہم نے اپنے اسکیمہ میں براہ راست ڈیٹا کلاسیفیکیشن ٹیگز شامل کیے۔
ڈیٹا ماڈل ڈیزائن کرنے سے پہلے تعمیل کے ماہرین اور ایک BA کو شامل کریں۔
- معیار (Standards) کافی نہیں ہیں
دونوں سسٹمز HL7 کو سپورٹ کرتے تھے۔ تاہم، ایک HL7 v2 استعمال کر رہا تھا اور دوسرا FHIR R4۔ وہ ایک ٹرانسلیشن لیئر کے بغیر ایک دوسرے سے رابطہ نہیں کر سکتے تھے۔
FHIR کے اندر بھی، ہمیں پروفائل کے عدم مطابقت (mismatches) کا سامنا کرنا پڑا۔ دونوں سسٹمز تعمیل کا دعویٰ کرتے تھے لیکن مختلف امپلیمنٹیشن گائیڈز استعمال کر رہے تھے۔
یہ فرض نہ کریں کہ انٹیگریشن آسان ہے صرف اس لیے کہ ایک سسٹم کسی معیار کو سپورٹ کرتا ہے۔ ہمیشہ مخصوص ورژن اور پروفائل کے بارے میں پوچھیں۔ ایک اڈاپٹر لیئر (adapter layer) کے لیے وقت مختص کریں۔
- ورک فلو ڈایاگرام پوشیدہ ایج کیسز (edge cases) کو پکڑ لیتے ہیں
میں ورک فلو ڈایاگرام کو اضافی دستاویزات سمجھتا تھا۔ میں غلط تھا۔
ہماری BA نے مریضوں کی منتقلی کا تفصیلی نقشہ تیار کیا۔ انہوں نے دیکھا کہ جب مریض علاج کے دوران منتقل ہوتا ہے یا جب ڈسچارج کے بعد لیب کا نتیجہ آتا ہے تو کیا ہوتا ہے۔
ہسپتال میں یہ کوئی غیر معمولی (edge cases) واقعات نہیں ہیں۔ یہ روزانہ پیش آتے ہیں۔
ان ڈایاگرامز نے ہمارے ڈیٹا ماڈل کو بدل دیا۔ ہم نے دونوں سسٹمز میں مسلسل دیکھ بھال کو ٹریک کرنے کے لیے 'کیئر ایپیسوڈ' (care episode) کا تصور شامل کیا۔
- شروع میں ہی ایک مشترکہ لغت (glossary) تیار کریں
'encounter' یا 'discharge' جیسے الفاظ مختلف سسٹمز میں مختلف معنی رکھتے ہیں۔ ہم نے وقت ضائع کیا کیونکہ ٹیموں نے اصطلاحات کی مختلف تشریح کی۔
ہماری BA نے ایک مشترکہ لغت تیار کی۔ ہر اسٹیک ہولڈر نے ان تعریفوں کا جائزہ لیا اور ان سے اتفاق کیا۔ ہم نے ہر ضرورت (requirement) میں اس دستاویز کا حوالہ دیا۔
فرض کریں کہ ہر ڈومین کی اصطلاح مبہم ہو سکتی ہے۔ اسے ایک ایسی دستاویز میں بیان کریں جس پر دونوں فریق دستخط کریں۔
خلاصہ
ایک مضبوط BA صرف ٹکٹس لکھنے سے کہیں زیادہ کام کرتا ہے۔ وہ ریگولیٹری پابندیوں اور کلینیکل مفہوم کے لیے آرکیٹیکٹس کے طور پر کام کرتے ہیں۔ اگر آپ پیچیدہ سافٹ ویئر بنا رہے ہیں، تو اس کردار کو اضافی بوجھ نہ سمجھیں۔ یہ تکنیکی کامیابی کو کلینیکل ناکامی بننے سے روکتا ہے۔
Optional learning community: https://t.me/GyaanSetuAi