سافٹ ویئر انجینئرنگ صحت کی معاشیات

یہ صحت کی معاشیات میں کیوں اہم ہے

ہر جدید صحت تنظیم، چاہے یہ تسلیم کرے یا نہ کرے، ایک سافٹ ویئر آپریٹر ہے۔ مریض ریکارڈز، نسخہ دینا، شیڈولنگ، لیبارٹری نتائج، ادائیگی کے دعوے، اور آبادی نگرانی سب کوڈ پر چلتے ہیں — وینڈرز سے خریدا گیا، اندرون-خانہ بنایا گیا، پیشروؤں سے وراثت میں پایا گیا، یا تینوں کے پار سلا گیا۔ شامل پیسہ بڑا اور دہرانے والا ہے: قومی الیکٹرانک صحت ریکارڈ پروگراموں نے اربوں ڈالر عوامی فنڈز خرچ کیے ہیں، اور صحت سافٹ ویئر کی چلانے کی لاگتیں — دیکھ بھال، انضمام، اپ گریڈز، سیکیورٹی — عام طور پر اس قیمت کو بونا کرتی ہیں جو اصل کاروباری کیس میں ظاہر ہوئی۔ پھر بھی زیادہ تر صحت-اقتصادی تربیت اس بارے میں کچھ نہیں کہتی کہ سافٹ ویئر ایک اقتصادی اثاثے کے طور پر کیسے برتاؤ کرتا ہے، اور زیادہ تر سافٹ ویئر-انجینئرنگ تربیت اس نظام میں مواقع کی لاگت کے بارے میں کچھ نہیں کہتی جو نرسیں اور دوائیں بھی خریدتا ہے۔

خلا اہمیت رکھتا ہے کیونکہ سافٹ ویئر خصوصیتی طریقوں سے اقتصادی طور پر ناکام ہوتا ہے جنہیں عام خریداری اضطراب نہیں پکڑتے۔ ایک نظام اس کی خریداری قیمت اور مظاہرے کی خصوصیات پر خریدا جاتا ہے؛ انضمام، ڈیٹا منتقلی، اور دیکھ بھال کا بوجھ بعد میں آتا ہے، ان بجٹوں کے خلاف جن سے کبھی مشورہ نہیں کیا گیا۔ ایک وینڈر تعلق انحصار میں سخت ہو جاتا ہے، تو ہر تجدید کمزوری سے گفت و شنید کی جاتی ہے۔ ڈیڈلائن دباؤ کے تحت اپنائے گئے شارٹ کٹس غیر مرئی طور پر جمع ہوتے ہیں یہاں تک کہ وہ نظام جو ہسپتال چلاتا ہے اب محفوظ طریقے سے بدلا نہیں جا سکتا — اس نکتے پر تنظیم کو ایک جدیدیت بل کا سامنا ہے جس کی اس نے کبھی منصوبہ بندی نہیں کی اور اسے مؤخر نہیں کر سکتی، کیونکہ سافٹ ویئر اب طبی خطرہ اٹھاتا ہے۔ بڑے صحت-IT پروگراموں کی تاریخ، بشمول UK کا National Programme for IT (2011 میں تقریباً £10 بلین کی تخمینہ لاگت کے بعد ختم کر دیا گیا)، قومی پیمانے پر ان حرکیات کی تاریخ ہے۔

ایک ڈائریکٹر کے لیے، داؤ تین گنا ہیں۔ پہلا، پیسہ: سافٹ ویئر ایک پوری-زندگی عہد ہے، اور خریداری پر سستا آپشن معمول کے طور پر ایک دہائی بھر مہنگا آپشن ہے۔ دوسرا، حفاظت: ایک طبی ترتیب میں ایک بندش، ایک ڈیٹا غلطی، یا ایک ناقابلِ-برقرار-رکھنے کے قابل نظام ایک تکلیف نہیں بلکہ ایک خطرہ ہے، ایسی لاگتوں کے ساتھ جو موضوع 3.11 — معیار اور حفاظت کی معاشیات میں اترتی ہیں۔ تیسرا، خودمختاری: بنانے اور خریدنے، ملکیتی اور کھلے نظاموں، اور معیاری اور مخصوص انٹرفیسز کے درمیان انتخاب طے کرتے ہیں تنظیم کے پاس پانچ سالوں میں کارروائی کرنے کی کتنی آزادی ہوگی — اور کارروائی کی آزادی، جیسا کہ یہ کتاب سارا وقت دلیل دیتی ہے، ایک اقتصادی اثاثہ ہے۔

بنیادی تصورات

سافٹ ویئر انجینئرنگ سافٹ ویئر کا منظم ڈیزائن، تعمیر، اور دیکھ بھال ہے — اور لفظ دیکھ بھال زیادہ تر معاشیات اٹھاتا ہے۔ ایک عمارت کے برعکس، سافٹ ویئر کبھی مکمل نہیں ہوتا: ضروریات بدلتی ہیں، ضوابط تبدیل ہوتے ہیں، انحصار پرانے ہوتے ہیں، اور سیکیورٹی خطرات ارتقا پاتے ہیں۔ سافٹ ویئر دیکھ بھال — سروس میں ایک نظام پر اصلاحی، موافقتی، اور احتیاطی کام — عام طور پر ایک نظام کی زندگی بھر کی لاگت کی اکثریت جذب کرتی ہے۔ اقتصادی تجزیے کی اکائی اس لیے کبھی خریداری نہیں ہے؛ یہ ملکیت کی کل لاگت ہے: حصول جمع انضمام، ڈیٹا منتقلی، تربیت، ہوسٹنگ، حمایت، اپ گریڈز، سیکیورٹی، اور حتمی ریٹائرمنٹ، نظام کی حقیقت پسندانہ زندگی بھر۔

دوسرا تصور تکنیکی قرض ہے: ایک سہولت مند ڈیزائن اب کے انتخاب کی مضمر مستقبل کی لاگت ایک مضبوط کے بجائے۔ استعارہ ایک مالیاتی میٹنگ میں استعمال کرنے کے لیے کافی درست ہے۔ قرض فطری طور پر برا نہیں ہے — ایک جان بوجھ کر شارٹ کٹ جو ایک ضروری صلاحیت جلد بھیجتا ہے ایک عقلی قرض ہو سکتا ہے — لیکن یہ سود جمع کرتا ہے: نظام میں ہر مستقبل کی تبدیلی اس کی وجہ سے زیادہ لاگت لیتی ہے، اور غیر-منظم قرض جمع ہوتا ہے یہاں تک کہ تبدیلی ناقابلِ برداشت طور پر مہنگی یا خطرناک بن جاتی ہے۔ ایک صحت تنظیم جو اپنا تکنیکی قرض نہیں دیکھ سکتی ایک غیر-بک شدہ ذمہ داری اٹھا رہی ہے، بالکل جیسے اس کے پاس غیر-ریکارڈ شدہ قرض ہو۔

تیسرا، وراثتی نظام: سافٹ ویئر جو اس نکتے سے آگے سروس میں رہتا ہے جہاں اسے اقتصادی طور پر برقرار رکھا جا سکتا ہے — اکثر کیونکہ یہ کام کرتا ہے، ہر کوئی اس پر منحصر ہے، اور اسے بدلنا خوفناک ہے۔ وراثت تنظیمی پیمانے پر تکنیکی قرض ہے، اور یہ ایک حقیقی تشخیصی مسئلہ پیش کرتی ہے: اسے رکھنے کی لاگتیں (بڑھتی دیکھ بھال، سیکیورٹی نمائش، عملہ جسے اب بھرتی نہیں کیا جا سکتا، کہیں اور بلاک شدہ بہتریاں) پھیلی اور بتدریج ہیں، جبکہ متبادل کی لاگت مرکوز، نظر آنے والی، اور سیاسی طور پر خطرناک ہے۔ دنیا بھر کے صحت نظام بالکل اسی وجہ سے دہائیوں پرانے سافٹ ویئر پر اہم خدمات چلاتے ہیں۔

چوتھا، انحصار۔ وینڈر لاک-اِن وہ حالت ہے جس میں ایک سپلائر سے دور بدلنا اتنا لاگت لیتا ہے — ڈیٹا منتقلی، دوبارہ تربیت، دوبارہ-انضمام، اور طبی خلل میں — کہ خریدار نے مؤثر گفت و شنید طاقت کھو دی ہے۔ صحت میں اسے ڈیٹا سے مزید بگاڑا جاتا ہے: مریض ریکارڈز کی ایک دہائی ایک ملکیتی فارمیٹ میں رکھی گئی ایک یرغمال ہے۔ لاک-اِن ایک حادثہ نہیں ہے؛ یہ ایک قیمتی حکمت عملی ہے، اور اس کی قیمت لگانے کا وقت دستخط سے پہلے ہے، تجدید پر نہیں۔ توازن معاہداتی ہیں (ڈیٹا-ایکسپورٹ حقوق، ایسکرو، خروج مدد) اور تعمیراتی — سب سے بڑھ کر، معیارات۔

پانچواں، ایک دوسرے سے تعاملیت: نظاموں کی معلومات تبادلہ کرنے اور جو تبادلہ کیا جاتا ہے اسے استعمال کرنے کی صلاحیت۔ اس کی معاشیات نیٹ ورک اثر کی معاشیات ہیں — ہر نظام جو ایک مشترکہ معیار بولتا ہے ہر دوسرے نظام کی قدر بڑھاتا ہے جو یہی کرتا ہے — یہی وجہ ہے کہ ایک دوسرے سے تعاملیت دائمی طور پر مارکیٹوں سے کم-فراہم شدہ ہے: فوائد پورے نظام کو جمع ہوتے ہیں جبکہ لاگتیں ہر وینڈر اور خریدار پر گرتی ہیں، اور ایک موجودہ کھلاڑی ایک دوسرے سے تعامل نہ کرنے سے فائدہ اٹھا سکتا ہے۔ Fast Healthcare Interoperability Resources (FHIR)، HL7 خاندان جس سے یہ تعلق رکھتا ہے، اور openEHR جیسے معیارات ان تبادلے کی لاگتوں کو کم کرنے کے لیے موجود ہیں، اور ضابطہ کاروں — مثال کے طور پر متحدہ ریاستیں 21st Century Cures Act معلومات-بلاکنگ قواعد کے ذریعے، اور یورپی یونین European Health Data Space کے ذریعے — نے وہ حکم دینا شروع کر دیا ہے جو مارکیٹ فراہم نہیں کر رہی تھی۔

چھٹا، بنانے-یا-خریدنے کا طیف، بشمول اوپن-سورس سافٹ ویئر — سافٹ ویئر جس کا سورس کوڈ آزادانہ طور پر استعمال اور تبدیل کے قابل ہے۔ اوپن سورس مفت نہیں ہے: لائسنس لاگت غائب ہو جاتی ہے، لیکن نفاذ، ہوسٹنگ، اور نگہبانی باقی رہتی ہے، اور کسی کو کوڈ برقرار رکھنا لازمی ہے۔ اس کی اقتصادی خصوصیت مختلف ہے — یہ لاک-اِن پریمیم ہٹاتی اور سافٹ ویئر کو ایک عام اچھائی میں بدلتی ہے جسے بہت سے خریدار مشترکہ طور پر مالی معاون کر سکتے ہیں، یہی وجہ ہے کہ DHIS2 اور OpenMRS جیسے پلیٹ فارمز کم- اور درمیانی-آمدنی ممالک میں زیادہ تر صحت-معلومات بوجھ اٹھاتے ہیں۔ بنانا-بمقابلہ-خریدنا کا فیصلہ، اسی طرح، ایک ٹیکنالوجی ترجیح نہیں بلکہ ایک پورٹ فولیو سوال ہے: وہاں بنائیں جہاں صلاحیت فرق کرنے والی ہے اور تنظیم ایک انجینئرنگ ٹیم برقرار رکھ سکتی ہے؛ وہاں خریدیں جہاں ضرورت عام ہے؛ اور کبھی وہ نہ بنائیں جسے آپ برقرار نہیں رکھ سکتے۔

آخر میں، ایک اقتصادی مقدار کے طور پر قابلیت اعتماد۔ طبی سافٹ ویئر ایسی خدمات چلاتا ہے جہاں بندش کی ایک صحت لاگت ہے، تو وہ انجینئرنگ نظم و ضبط جو نظاموں کو قابلِ اعتماد رکھتے ہیں — بشمول سائٹ ریلائیبلٹی انجینئرنگ، جو واضح اہداف اور قابلِ قبول ناکامی کے لیے بجٹ کے خلاف قابلیت اعتماد کا انتظام کرتی ہے — بہترین طور پر بیمہ خریدنے کے طور پر سمجھی جاتی ہے جس کا پریمیم انجینئرنگ کوشش ہے۔ طبی ترتیب کی ضرورت سے اوپر قابلیت اعتماد فضول ہے؛ اس سے نیچے، کمی واقعات میں ادا کی جاتی ہے۔ اس سب کی تشخیصی مشینری موضوع 2.1 — اقتصادی جائزہ اور موضوع 2.5 — بجٹ اثر اور استطاعت کا استطاعت نظم و ضبط رہتی ہے؛ یہ موضوع سافٹ ویئر-مخصوص لاگت ساخت فراہم کرتا ہے جسے ان طریقوں کو کھلایا جانا لازمی ہے۔ ایک ڈیجیٹل اوزار کو صحت مداخلت کے طور پر جانچنا — کیا ایپ یا ٹیلی ہیلتھ خدمت قابلِ قبول لاگت پر نتائج بہتر کرتی ہے — موضوع 5.2 — ڈیجیٹل صحت کی معاشیات سے تعلق رکھتی ہے؛ خاص طور پر AI ماڈلز کی معاشیات موضوع 5.3 — AI صحت کی معاشیات سے۔

بہترین طریقے

1. نظام کی حقیقت پسندانہ زندگی بھر ملکیت کی کل لاگت جانچیں، کبھی خریداری قیمت نہیں۔ ہر سافٹ ویئر کاروباری کیس کا مطالبہ کریں کہ حصول، انضمام، ڈیٹا منتقلی، تربیت، ہوسٹنگ، حمایت، سیکیورٹی، اپ گریڈز، اور ریٹائرمنٹ کی لاگت ایک بیان کردہ افق پر — عام طور پر ایک دہائی یا اس سے زیادہ — لگائے، اور نام لے کون سا بجٹ ہر دہرائی جانے والی لائن اٹھاتا ہے۔ ایک لائسنس فیس کسی چیز کے خلاف موازنہ نہ کی گئی ایک کاروباری کیس نہیں ہے؛ یہ ایک عہد کی نظر آنے والی چوٹی ہے۔

2. تکنیکی قرض کو کتابوں پر رکھیں۔ انجینئرنگ رہنماؤں کو اسٹیٹ میں اہم شارٹ کٹس اور بوڑھے اجزاء کا ایک رجسٹر برقرار رکھیں، ایک دیانتدار تخمینے کے ساتھ کہ ہر ایک کتنا سود چارج کر رہا ہے — سست تبدیلیاں، زیادہ واقعہ خطرہ، بلاک شدہ بہتریاں۔ اسے ایک مالیاتی ذمہ داری جیسی سنجیدگی سے جائزہ لیں، اور اسے ادا کرنے کے لیے انجینئرنگ صلاحیت کا ایک مستقل حصہ (عام طور پر ایک پانچواں سے ایک تہائی) بجٹ رکھیں، کیونکہ مؤخر شدہ قرض کی خدمت جمع شدہ قرض ہے۔

3. پہلے دن سے دیکھ بھال کو ایک آپریٹنگ لاگت کے طور پر مالی معاون کریں۔ سافٹ ویئر جو "مکمل" ہے سافٹ ویئر ہے جو زوال پذیر ہو رہا ہے: انحصار پرانا ہوتا، خطرات ارتقا پاتے، ضوابط تبدیل ہوتے ہیں۔ اصل تشخیص اور دہرائی جانے والے بجٹ میں دیکھ بھال دھارے بنائیں، اور ایک تجویز کو جس میں کوئی دیکھ بھال لائن نہیں نامکمل سمجھیں — پیسہ کسی نہ کسی طرح خرچ ہوگا، اور واحد سوال یہ ہے کہ آیا اس کی منصوبہ بندی کی گئی تھی یا ایک بحران سے نکالا گیا۔

4. دستخط سے پہلے لاک-اِن کی قیمت لگائیں، تجدید پر نہیں۔ ہر بڑی خریداری کے لیے، خروج کی لاگت کریں جب آپ کے پاس ابھی بھی متبادلات ہیں: ڈیٹا کا مالک کون ہے، یہ کس فارمیٹ میں ایکسپورٹ کیا جا سکتا ہے، وینڈر کو کون سی خروج مدد فراہم کرنی لازمی ہے، اور ایک منتقلی قابلِ فہم طور پر کیا لاگت لے گی۔ ڈیٹا-ایکسپورٹ حقوق اور کھلے انٹرفیس معاہدے میں گفت و شنید کریں، اور ان کے خلاف وینڈر کی مزاحمت کو آنے والی تجدید گفت و شنید کے بارے میں معلومات سمجھیں۔

5. ایک دوسرے سے تعاملیت جان بوجھ کر خریدیں، کیونکہ مارکیٹ اسے کم-فراہم کرتی ہے۔ کھلے معیارات — FHIR اور اس کے رشتہ داروں — کی حمایت خریداری کی ایک شرط کے طور پر مانگیں، دعویٰ کردہ تعمیل کو اپنے حقیقی ڈیٹا بہاؤ کے خلاف تصدیق کریں ایک بروشر کے بجائے، اور مخصوص انٹرفیس رد کریں جہاں ایک معیاری موجود ہو۔ ہر ملکیتی انٹرفیس جسے آپ قبول کرتے ہیں ایک تبدیلی لاگت ہے جو آپ نے وینڈر کو عطیہ کی ہے اور ہر مستقبل کے انضمام پر ایک ٹیکس۔

6. بنانا-بمقابلہ-خریدنا ایک پورٹ فولیو کے طور پر فیصلہ کریں، اپنی انجینئرنگ صلاحیت سے ملایا گیا۔ صرف وہاں بنائیں جہاں صلاحیت آپ کی خدمت کو فرق کرتی ہے اور آپ حقیقتاً بھرتی، برقرار، اور ایک ٹیم کی مالی معاونت کر سکتے ہیں جو آپ جو بناتے ہیں اسے برقرار رکھے — ایک اندرون-خانہ نظام بغیر ایک مستقل ٹیم کے اضافی قدموں کے ساتھ ایک وراثتی نظام ہے۔ عام ضروریات خریدیں؛ اوپن-سورس پلیٹ فارمز پر غور کریں جہاں ایک کمیونٹی یا عوامی کنسورشیم انہیں برقرار رکھتا ہے؛ اور استحکام منصوبہ فیصلے میں لکھیں، جو بھی راستہ ہو۔

7. اوپن سورس کو اپنی ساخت لاگت والا ایک خریداری آپشن سمجھیں، مفت کے طور پر نہیں۔ اسے ملکیت کی کل لاگت پر موازنہ کریں: کوئی لائسنس فیس نہیں، لیکن حقیقی نفاذ، ہوسٹنگ، حمایت، اور نگہبانی لاگتیں، چاہے اندرون-خانہ اٹھائی جائیں یا ایک حمایت سپلائر کے ذریعے۔ اس کے منفرد فوائد کو تولیں — کوئی لاک-اِن پریمیم نہیں، معائنہ کے قابل کوڈ، دیگر صحت اداروں کے ساتھ ایک عام اچھائی مشترکہ طور پر مالی معاون کرنے کی صلاحیت — اور اس کا منفرد فرض: اگر آپ اس پر منحصر ہیں، اسے برقرار رکھنے میں حصہ ڈالیں۔

8. طبی نتیجے سے قابلیت اعتماد اہداف طے کریں، اور ہدف تک خرچ کریں۔ فیصلہ کریں، خدمت بہ خدمت، ایک گھنٹے کی بندش اصل میں کیا لاگت لیتی ہے — تاخیر شدہ نگہداشت، غیر محفوظ حل، اور کھویا اعتماد میں — اور اسی کے مطابق دستیابی اور بحالی کے مقاصد طے کریں۔ پھر انجینئرنگ خرچ کو دونوں اطراف سے ہدف تک رکھیں: کلینک کی ضرورت سے کم قابلیت اعتماد کے لیے ادائیگی واقعات خریدتی ہے، اور اس سے زیادہ کے لیے ادائیگی سونا-پلیٹنگ خریدتی ہے۔

9. وراثتی متبادل کی منصوبہ بندی کریں اس سے پہلے کہ یہ مجبور ہو۔ اہم نظاموں کی عمر اور برقرار رکھنے کی قابلیت کا ایک سائیکل پر جائزہ لیں، اور متبادل شروع کریں جبکہ موجودہ کھلاڑی اب بھی کام کرتا ہے — ناکامی کے تحت انجام دی گئی ایک منتقلی سب سے مہنگی قسم ہے۔ تدریجی منتقلی (انٹرفیس بہ انٹرفیس پرانے نظام کو گلا گھونٹنا) کو بڑے-دھماکے کٹ اوورز پر ترجیح دیں، جن کا ناکامی موڈ صحت میں منسوخ کلینکس اور کھوئے گئے ریکارڈز میں ناپا جاتا ہے۔

10. ڈیٹا منتقلی کو ہر تشخیص میں ایک پہلی-درجے کی لائن بنائیں۔ مریض ڈیٹا ہر اس نظام سے آگے زندہ رہتا ہے جو اسے رکھتا ہے، اور اسے منتقل کرنا — صاف طور پر، مکمل طور پر، طبی حفاظت کے ساتھ یقینی — معمول کے طور پر کسی بھی منتقلی کی سب سے بڑی اور سب سے زیادہ کم-تخمینہ شدہ لاگتوں میں سے ہے۔ اسے واضح طور پر لاگت دیں، اسے حقیقی ریکارڈز کے ساتھ جلد جانچیں، اور ایک نظام کی زندگی بھر اپنے ڈیٹا کی تحویل ایک ایکسپورٹ کے قابل شکل میں رکھیں تاکہ منتقلی کبھی جانے والے وینڈر کی یرغمال نہ بنے۔

11. طبی-حفاظت انجینئرنگ کو معاشیات کے اندر رکھیں۔ صحت سافٹ ویئر حفاظت-متعلقہ سافٹ ویئر ہے: تبدیلیوں کو جانچ کی ضرورت ہے، ریلیز کو واپسی راستوں کی ضرورت ہے، واقعات کو تفتیش کی ضرورت ہے، اور دائرہ کار تیزی سے صحت IT پر باقاعدہ طبی-خطرہ معیار مسلط کرتے ہیں۔ یہ نظم و ضبط انجینئرنگ وقت لیتے ہیں اور کاروباری کیس میں تعلق رکھتے ہیں — ایک "سستی" ترسیل جو انہیں چھوڑ دیتی ہے مریضوں کو لاگت خطرے کے طور پر منتقل کر رہی ہے (نقصان کی لاگت موضوع 3.11 — معیار اور حفاظت کی معاشیات ہے)۔

12. سافٹ ویئر فیصلوں کو کسی بھی دوسری صحت سرمایہ کاری کی طرح اسی قدر جانچ سے گزاریں۔ ایک سافٹ ویئر پروگرام دواؤں اور عملے کے ساتھ اسی محدود بجٹ کے لیے مقابلہ کرتا ہے، تو یہ وہی نظم و ضبط واجب الادا ہے: ایک بیان کردہ فائدہ، ایک حقیقی موازنہ کنندہ (بشمول "جو ہمارے پاس ہے اسے بہتر کریں")، وقت کے ساتھ ایک استطاعت پروفائل، اور کیے گئے وعدوں کے خلاف نفاذ-کے-بعد جائزہ (مشینری موضوع 2.1 — اقتصادی جائزہ اور موضوع 2.5 — بجٹ اثر اور استطاعت ہے، اور خریداری کا ہنر موضوع 3.10 — اسٹریٹجک خریداری اور کمیشننگ ہے)۔

اپنی ٹیم کے ساتھ گفتگو کے لیے سوالات

1. ہمارا سافٹ ویئر اسٹیٹ فی سال حقیقتاً کیا لاگت لیتا ہے، اور اس کا کتنا حصہ ہم نے منصوبہ بند کیا؟ زیادہ تر تنظیمیں اپنی لائسنس فیس نام لے سکتی ہیں لیکن اپنی انضمام، دیکھ بھال، سیکیورٹی، اور حل کی لاگتیں نہیں، جو تنظیم بھر آپریشنل بجٹوں اور عملے کے وقت میں چھپتی ہیں۔ ٹیم سے پوچھیں سرفہرست مٹھی بھر نظاموں کے لیے حقیقی سالانہ عدد جمع کریں اور اس کا موازنہ کریں جس کا اصل کاروباری کیسز نے وعدہ کیا۔ ٹینشن یہ ہے کہ پھیلی ہوئی لاگتوں کا کوئی واحد مالک نہیں، تو کوئی ان کی ترقی کے لیے جوابدہ نہیں، اور وہ لوگ جنہوں نے خریداری منظور کی شاذ و نادر ہی وہی لوگ ہیں جو دیکھ بھال ادا کرتے ہیں۔ ایک دیانتدار جواب ایک پوری-زندگی عدد پیدا کرتا ہے، بیان کرتا ہے کون سے بجٹ اسے اٹھاتے ہیں، اور تسلیم کرتا ہے کہاں خرچ غیر منصوبہ بند ہے — کیونکہ ایک لاگت جسے آپ سالانہ واجب الادا میں دریافت کرتے ہیں ایک لاگت ہے جسے آپ منظم نہیں کر سکتے۔

2. ہمارا تکنیکی قرض کہاں ہے، اور ہم اس پر کیا سود ادا کر رہے ہیں؟ انجینئرنگ ٹیمیں عام طور پر بالکل جانتی ہیں قرض کہاں ہے — وہ ماڈیول جسے کوئی چھونے کی ہمت نہیں کرتا، وہ انٹرفیس جو دستی قدموں سے جڑا ہوا ہے، وہ پلیٹ فارم جو سیکیورٹی حمایت پر دو ورژن پیچھے ہے — لیکن یہ علم شاذ و نادر ہی اقتصادی زبان میں بورڈ تک پہنچتا ہے۔ رجسٹر مانگیں: اہم قرضے، ہر ایک کیا سست کرتا یا خطرے میں ڈالتا ہے، اور اسے ادا کرنا کیا لاگت لے گا۔ ٹینشن یہ ہے کہ قرض ادائیگی نظر آنے والی نئی خصوصیات سے مقابلہ کرتی ہے اور ہمیشہ ظاہری شکل پر ہارتی ہے، جو بالکل وہی طریقہ ہے جس سے قرض جمع ہوتا ہے۔ ایک دیانتدار جواب سود (سست ترسیل، واقعہ نمائش، بلاک شدہ منصوبے) مقدار متعین کرتا ہے، کمی کے لیے صلاحیت کا ایک مستقل حصہ عہد کرتا ہے، اور قبول کرتا ہے کہ کچھ قرض رکھنا عقلی ہے — بشرطیکہ اسے جانتے بوجھتے رکھا جائے۔

3. اگر ہمیں تین سالوں میں اپنا مرکزی نظام وینڈر چھوڑنا پڑے، کیا ہم کر سکتے، اور اس کی کیا لاگت ہوگی؟ یہ سوال لاک-اِن سامنے لاتا ہے جبکہ اسے کم کرنے کا وقت اب بھی ہے۔ تحقیقات کریں کون ڈیٹا کا مالک ہے اور یہ کس فارمیٹ میں جا سکتا ہے، معاہدہ خروج مدد کے بارے میں کیا کہتا ہے، کتنے مخصوص انٹرفیس دوبارہ بنانے کی ضرورت ہوگی، اور ایک منتقلی کیا دوبارہ تربیت اور طبی خلل مسلط کرے گی۔ ٹینشن یہ ہے کہ ہر کوئی امید کرتا ہے کبھی خروج کا استعمال نہیں کرے گا، تو کوئی اسے کھلا رکھنے کے لیے ادا نہیں کرنا چاہتا — پھر بھی ایک خروج جو ناممکن ہے ایک تجدید گفت و شنید ہے جو پہلے ہی ہار گئی۔ ایک دیانتدار جواب خروج کی قیمت لگاتا ہے، ان دو یا تین اقدامات کی شناخت کرتا ہے جو اسے سستا کریں گے (ڈیٹا-ایکسپورٹ حقوق، معیاری انٹرفیس، دستاویزات)، اور اس قیمت کو ایک گفت و شنید کی پوزیشن سمجھتا ہے جسے تنظیم فعال طور پر برقرار رکھتی ہے۔

4. کون سے نظام ہمیں بنانے چاہئیں، کون سے خریدنے چاہئیں، اور کیا ہماری انجینئرنگ صلاحیت اس جواب سے میل کھاتی ہے؟ بنانا-بمقابلہ-خریدنا تقسیم ایک پورٹ فولیو فیصلہ ہے جسے بہت سی تنظیمیں انتخاب کی بجائے جمع سے کرتی ہیں، عام چیزیں بناتے ہوئے اور وہ خریدتے ہوئے جو انہیں فرق کرتا ہے ختم ہوتی ہیں۔ پوچھیں آپ کے کون سے نظام حقیقتاً آپ کی خدمت کے بارے میں کچھ مخصوص مجسم کرتے ہیں اور کون سے عام ضروریات ہیں جو ایک مارکیٹ یا اوپن-سورس کمیونٹی پہلے سے خدمت کرتی ہے۔ پھر صلاحیت کے دعوے جانچیں: ہر اس چیز کے لیے جو اندرون-خانہ بنائی گئی، کیا ایک مالی معاون، بھرتی کے قابل ٹیم موجود ہے جو اس کی پوری زندگی بھر برقرار رکھنے کا عہد کرتی ہے — صرف وہ منصوبہ نہیں جس نے اسے بنایا؟ ٹینشن یہ ہے کہ بنانا خواہش کو خوشامد کرتا ہے اور خریدنا احتیاط کو، اور کوئی بھی جبلت تجزیہ نہیں ہے۔ ایک دیانتدار جواب فرق کرنے والی چیزوں کا نام لیتا ہے، تسلیم کرتا ہے کہاں پچھلی تعمیرات ریٹائر یا معیاری مصنوعات سے تبدیل ہونی چاہئیں، اور کسی بھی تعمیر کو شروع کرنے سے انکار کرتا ہے جس کی دیکھ بھال غیر-مالی معاون ہے۔

5. ہمارے سب سے اہم نظام میں ایک گھنٹے کی بندش اصل میں کیا لاگت لیتی ہے، اور کیا ہمارا قابلیت اعتماد خرچ اس سے میل کھاتا ہے؟ قابلیت اعتماد فیصلے اکثر انجینئرز کے ذریعے طبی-لاگت معلومات کے بغیر کیے جاتے ہیں، یا بورڈز کے ذریعے انجینئرنگ-لاگت معلومات کے بغیر، تو خرچ عادت سے ملایا جاتا ہے، نتیجے سے نہیں۔ ایک ٹھوس منظرنامے کے ذریعے کام کریں: ایک مصروف دن بھر الیکٹرانک ریکارڈ بند ہے — کیا تاخیر ہوتی ہے، کیا غیر محفوظ حل ظاہر ہوتے ہیں، کیا نقصان قابلِ فہم طور پر پیروی کرتا ہے، بحالی کیا لاگت لیتی ہے؟ پھر اس کا موازنہ کریں جو آپ لچک، بیک اپس، فیل اوور، اور واقعہ ردعمل پر خرچ کرتے ہیں۔ ٹینشن دونوں طرح چلتا ہے: کم-خرچ کرنا واقعات خریدتا ہے، لیکن ایک کم-داؤ نظام کو سونا-پلیٹ کرنا وہ پیسہ ضائع کرتا ہے جس کی کسی اور خدمت کو ضرورت ہے۔ ایک دیانتدار جواب فی اہم خدمت ایک واضح دستیابی اور بحالی ہدف طے کرتا ہے، طبی نتیجے سے اخذ شدہ، اور وہ انجینئرنگ خرچ دکھا سکتا ہے جو اسے پورا کرتا ہے — نہ زیادہ، نہ کم۔

6. ان وراثتی نظاموں کے لیے ہمارا منصوبہ کیا ہے جنہیں چھونے سے سب ڈرتے ہیں؟ ہر بالغ صحت تنظیم کے پاس یہ ہیں: نظام جو اقتصادی برقراری سے آگے ہیں، زندہ رکھے گئے کیونکہ وہ کام کرتے ہیں اور متبادل خوفناک ہے۔ اپنوں کا نام لیں۔ پوچھیں ہر ایک کیا بلاک کرتا ہے — نہ بنائے گئے انضمام، نہ کی گئی بہتریاں، اٹھائی گئی سیکیورٹی نمائش — اور متبادل راستہ کیا ہے: تدریجی منتقلی، مکمل متبادل، یا جان بوجھ کر، منصوبہ بند برقراری محدود خطرے کے ساتھ۔ ٹینشن وقتی ہے: وراثت رکھنے کی لاگتیں پھیلی اور سالانہ ہیں جبکہ اسے بدلنے کی لاگت مرکوز اور کیریئر-نظر آنے والی ہے، تو عقلی-لگنے والی مؤخری ڈیفالٹ ہے یہاں تک کہ ناکامی بدترین ممکنہ قیمت پر مسئلہ مجبور کرے۔ ایک دیانتدار جواب متبادل کا شیڈول بناتا ہے جبکہ موجودہ کھلاڑی اب بھی کام کرتا ہے، بڑے-دھماکے کٹ اوور پر گلا-گھونٹنے-طرز تدریجی منتقلی کو ترجیح دیتا ہے، اور "ہم اگلے سال فیصلہ کریں گے" کو اس فیصلے کے طور پر برتتا ہے جو یہ اصل میں ہے۔

عملی تناظر میں: ایک صحت اقتصادیات کی مثال

مشرقی افریقہ کے ایک فرضی ملک کی وزارتِ صحت کو ایک تجدید فیصلے کا سامنا ہے۔ نو سالوں سے اس کے علاقائی ہسپتال ایک بیرون ملک وینڈر کا فراہم کردہ ملکیتی ہسپتال-معلومات نظام چلاتے ہیں۔ نظام کام کرتا ہے، لیکن تجدید کوٹیشن تیزی سے بڑھی ہے، ہر نیا انٹرفیس — قومی بیمہ اسکیم کو، لیبارٹری نیٹ ورک کو — ایک مخصوص، وینڈر-قیمت شدہ منصوبہ ہے، اور معاہدہ ڈیٹا ایکسپورٹ پر خاموش ہے۔ اسی دوران وزارت کے ضلعی صحت دفاتر پہلے سے DHIS2 چلاتے ہیں، قومی صحت شماریات کے لیے استعمال شدہ اوپن-سورس پلیٹ فارم، اور ایک ہمسایہ ملک نے ایک علاقائی حمایت کنسورشیم کے ساتھ ایک اوپن-سورس طبی-ریکارڈ پلیٹ فارم نافذ کیا ہے۔

وزارت کی صحت-اقتصادیات یونٹ فیصلے کو "تجدید کریں یا نہیں" سے دس سالوں پر تین آپشنز کے پوری-زندگی موازنے میں دوبارہ فریم کرتی ہے: موجودہ کو تجدید کریں، خروج حقوق بناتے ہوئے مختصر-مدت تجدید کریں، یا اوپن-سورس پلیٹ فارم کی طرف تدریجی طور پر منتقل ہوں۔ آپشنز کی لاگت کاری حقیقی معاشیات بے نقاب کرتی ہے۔ موجودہ کا لائسنس اس کی حقیقی سالانہ لاگت کا صرف ایک تہائی ہے ایک بار مخصوص انٹرفیسز، لازمی اپ گریڈ منصوبے، اور بیرون-ملک حمایت سفر گنے جائیں۔ اوپن-سورس آپشن کوئی لائسنس نہیں اٹھاتا لیکن وزارت کو ایک قومی حمایت ٹیم، علاقائی ہوسٹنگ، اور پلیٹ فارم کی کمیونٹی میں ایک شراکت مالی معاون کرنے کی ضرورت ہے — حقیقی، دہرائی جانے والی رقم جسے "مفت سافٹ ویئر" بیانیہ چھپاتا تھا۔ فیصلہ کن لائن، تاہم، ان میں سے کوئی نہیں ہے: یہ ڈیٹا منتقلی ہے۔ مریض ریکارڈز کے نو سال ایک ملکیتی اسکیمے میں بیٹھتے ہیں، اور استخراج مدد کے لیے وینڈر کی قیمت، مؤثر طور پر، چھوڑنے کی قیمت ہے۔

یونٹ بہرحال خروج کی قیمت لگاتی ہے، اور عدد گفت و شنید بدلتا ہے۔ ایک لاگت شدہ متبادل سے مسلح، وزارت ایک دو-سالہ تجدید کم قیمت پر گفت و شنید کرتی ہے جس میں ایک دستاویز شدہ فارمیٹ میں معاہداتی ڈیٹا-ایکسپورٹ اور بیمہ اسکیم اور لیبارٹری نیٹ ورک تک معیاری FHIR انٹرفیس شامل ہیں — اقتصادی شرائط میں خریدے گئے، ایک سستے مستقبل خروج پر ایک آپشن کے طور پر، اس طریقے سے قدر دی گئی جس طرح موضوع 3.12 — وبائی امراض اور ہنگامی تیاری کی معاشیات مستقبل کارروائی کی آزادی پر کسی بھی آپشن کی قدر متعین کرتا ہے۔ ان دو سالوں کے دوران، ایک پائلٹ تین ضلعی ہسپتالوں کو اوپن-سورس پلیٹ فارم میں منتقل کرتا ہے، حمایت کنسورشیم، ڈیٹا-منتقلی آلات، اور — اہم طور پر — آیا وزارت ان انجینئرز کو بھرتی اور برقرار رکھ سکتی ہے جن کی پلیٹ فارم کو ضرورت ہے، موضوع 3.6 — صحت کی افرادی قوت اور لیبر مارکیٹس کی افرادی-قوت معاشیات پر ٹیک لگاتے ہوئے جانچتا ہے۔

پائلٹ دو ہسپتالوں میں کامیاب ہوتی ہے اور تیسرے میں جدوجہد کرتی ہے، جہاں عملے کے خلا ہر واقعے کو ایک بحران بناتے ہیں — صلاحیت کے بارے میں ایک انتباہ، سافٹ ویئر کے بارے میں نہیں۔ وزارت پانچ سالوں بھر ایک مرحلہ وار قومی منتقلی کے ساتھ آگے بڑھتی ہے، ہسپتال بہ ہسپتال، موجودہ کو متوازی طور پر چلاتی رکھتے ہوئے جب تک ہر سائٹ کا ڈیٹا تصدیق شدہ نہ ہو۔ حتمی تشخیص سبق واضح بناتی ہے: جیتنے والا اقدام ملکیتی پر اوپن سورس چننا نہیں تھا، بلکہ ہر آپشن کی پوری زندگی کی قیمت لگانا، انحصار مزید سخت ہونے سے پہلے خروج حقوق خریدنا، اور انجینئرنگ عہد کو اس سے ملانا جسے وزارت اصل میں برقرار رکھ سکتی تھی۔

چار شعبہ جاتی عدسے

اسٹارٹ اپ

ایک صحت-سافٹ ویئر اسٹارٹ اپ بیچنے کے پہلو سے اس موضوع کی معاشیات زندہ کرتا ہے: اس کی قدر ترسیل کی رفتار کا انعام دیتی ہے، جو بالکل ویسے ہی ہے جیسے تکنیکی قرض جمع ہوتا ہے، اور اس کا آمدنی ماڈل خاموشی سے اس لاک-اِن پر منحصر ہو سکتا ہے جس کی اس کے صارفین کو مزاحمت کرنی چاہیے۔ نظم و ضبط قرض کو جان بوجھ کر لینا ہے — ایک شارٹ کٹ جو ایک محوری صارف جیتتا ہے عقلی ہو سکتا ہے — ایک رجسٹر اور ادائیگی منصوبہ رکھتے ہوئے، کیونکہ ایک کوڈ بیس جسے بدلا نہیں جا سکتا ایک کمپنی ہے جو پیوٹ نہیں کر سکتی۔ ایک دوسرے سے تعاملیت حکمت عملی ہے، تعمیل نہیں: معیاری انٹرفیس (سب سے بڑھ کر FHIR) وہی ہیں جن سے ایک چھوٹی مصنوع موجودہ کھلاڑیوں سے غالب اسٹیٹس کے اندر ایک جگہ کماتی ہے۔ اور طبی-حفاظت انجینئرنگ کوئی بیوروکریسی نہیں جسے پیمانے تک مؤخر کرنا ہے؛ ایک طبی ترتیب میں ایک ڈیٹا-سالمیت واقعہ ایک جوان کمپنی ختم کر سکتا ہے۔

چھوٹا کاروبار

ایک چھوٹا لیکن قائم شدہ فراہم کنندہ — ایک کلینک گروپ، ایک فارمیسی چین، ایک تشخیصی لیبارٹری — اپنا تقریباً تمام سافٹ ویئر خریدتا ہے اور اس کے پاس ایک بری خریداری کی تلافی کرنے کے لیے کوئی انجینئرنگ عملہ نہیں ہے، تو اس کی معاشیات انحصار کی معاشیات ہیں۔ ملکیت کی کل لاگت اور خروج حقوق یہاں کہیں بھی زیادہ اہمیت رکھتے ہیں، کیونکہ ایک غلط-قیمت نظام متناسب طور پر بجٹ کا ایک بڑا حصہ ہے اور ایک ناکام منتقلی کاروبار روک سکتی ہے۔ معقول انداز معیاربندی ہے: مین اسٹریم مصنوعات، کھلے-معیار انٹرفیس، خود-چلائے گئے سرورز کے بجائے ہوسٹ شدہ خدمات، اور قیمت سے پہلے ڈیٹا-ایکسپورٹ شقوں کے لیے پڑھے گئے معاہدے۔ اس کا منفرد خطرہ خاموش وراثت ہے — پریکٹس-انتظام نظام جو جگہ پر پرانا ہوتا ہے یہاں تک کہ اس کا سپلائر بند ہو جائے — تو یہاں تک کہ ایک چھوٹے خریدار کو ہر سال معلوم ہونا چاہیے کہ ہر نظام کو چھوڑنے کی کیا لاگت ہوگی جس پر یہ منحصر ہے۔

ادارہ

ایک بڑا ہسپتال گروپ یا بیمہ کنندہ سینکڑوں نظام چلاتا ہے، تو اس کا مسئلہ پورٹ فولیو ہے: مختلف محکموں کے خریدے گئے اوورلیپنگ مصنوعات، ایک انضمام ویب جسے کوئی مکمل طور پر نقشہ نہیں بناتا، اور ایک اسٹیٹ بھر تقسیم شدہ تکنیکی قرض جو کسی ایک ٹیم کے دیکھنے کے لیے بہت بڑا ہے۔ بالغ ادارہ اسٹیٹ کو اسی طرح منظم کرتا ہے جس طرح یہ ایک سرمایہ کاری پورٹ فولیو منظم کرتا ہے — مالکان، پوری-زندگی لاگتوں، قرض اور خطرے کی درجہ بندیوں، اور منصوبہ بند متبادل افقوں کے ساتھ نظاموں کی ایک انوینٹری — اور انضمام، قابلیت اعتماد، اور ادائیگی کے لیے ایک مستقل انجینئرنگ صلاحیت مالی معاون کرتا ہے ہر بہتری کو بولی کے قابل منصوبے کے طور پر برتنے کے بجائے۔ پیمانہ اسے خریداری طاقت بھی دیتا ہے جو چھوٹے خریدار کے پاس نہیں: یہ معیاری انٹرفیس، ڈیٹا-ایکسپورٹ حقوق، اور ایسکرو داخلے کی شرائط کے طور پر مانگ سکتا ہے، اور اس کی آرکیٹیکچر انتخاب اس کے وینڈرز کو نظم دیتے ہیں الٹ کے بجائے۔

حکومت

ایک وزارت یا قومی پیئر باقی سب کے لیے یہ معاشیات شکل دیتی ہے۔ یہ ایک دوسرے سے تعاملیت قواعد طے کرتی ہے جو طے کرتے ہیں آیا مارکیٹ کھلے پن کا انعام یا سزا دیتی ہے — جیسے متحدہ ریاستوں نے 21st Century Cures Act کی معلومات-بلاکنگ شقوں سے اور یورپی یونین نے European Health Data Space سے کیا — اور اس کی اپنی خریداری وینڈرز کو سکھاتی ہے کہ خریدار کیا برداشت کریں گے۔ اس کا منفرد ناکامی طریقہ قومی میگا-پروگرام ہے: مرکزی، بڑا-دھماکہ، سیاسی طور پر شیڈول شدہ سافٹ ویئر ترسیل جس کا خاتمہ اربوں میں ناپا جاتا ہے، جیسا کہ UK کے National Programme for IT نے ظاہر کیا۔ نظم و ضبط الٹا انداز ہے — مرکزی طور پر معیارات اور پلیٹ فارمز، تدریجی طور پر ترسیل، اوپن-سورس اور مقامی-طور-پر-برقرار-رکھنے-کے-قابل آپشنز کو سنجیدگی سے تولتے ہوئے جہاں تجارتی مارکیٹیں پتلی ہوں (پالیسی مشینری موضوع 3.2 — صحت کی پالیسی ہے، اور خریداری کا ہنر موضوع 3.10 — اسٹریٹجک خریداری اور کمیشننگ ہے)۔

عام ناکامی کے طریقے

• لائسنس خریدنا، زندگی نہیں۔ خریداری قیمت پر سافٹ ویئر منظور کرنا جبکہ انضمام، منتقلی، دیکھ بھال، اور خروج غیر-لاگت شدہ چھوڑنا۔ حل: ہر کاروباری کیس میں پوری-زندگی ملکیت کی کل لاگت کا مطالبہ کریں، ہر دہرائی جانے والی لائن کے لیے نام زد بجٹ کے ساتھ۔
• غیر مرئی قرض جب تک وہ جمع نہ ہو۔ تکنیکی قرض کو غیر-ریکارڈ شدہ جمع ہونے دینا یہاں تک کہ اسٹیٹ کو محفوظ طور پر بدلا نہ جا سکے۔ حل: ایک قرض رجسٹر رکھیں، اسے اقتصادی شرائط میں رپورٹ کریں، اور ادائیگی کے لیے مستقل صلاحیت عہد کریں۔
• لاک-اِن میں نیند چلتے ہوئے چلنا۔ ملکیتی فارمیٹس اور مخصوص انٹرفیس قبول کرنا یہاں تک کہ خروج ناقابلِ برداشت ہو اور تجدیدات حکم دی جائیں۔ حل: خریداری پر ڈیٹا-ایکسپورٹ حقوق اور معیاری انٹرفیس گفت و شنید کریں، اور سالانہ خروج کی قیمت لگائیں۔
• وہ بنانا جسے آپ برقرار نہیں رکھ سکتے۔ بغیر ایک مالی معاون ٹیم کے پوری زندگی کے لیے اندرون-خانہ نظام کمیشن کرنا۔ حل: استحکام منصوبے کے بغیر کوئی تعمیر نہیں؛ جہاں صلاحیت پتلی ہو اوپن-سورس پلیٹ فارمز خریدیں یا اپنائیں۔
• اوپن سورس کو مفت سمجھنا۔ ہوسٹنگ، حمایت، اور نگہبانی مالی معاون کیے بغیر کمیونٹی پلیٹ فارمز اپنانا۔ حل: اوپن سورس کو ملکیت کی کل لاگت پر جانچیں اور اس استحکام کا بجٹ رکھیں جس کی اسے ضرورت ہے۔
• امید سے قابلیت اعتماد۔ دستیابی اہداف کو غیر-طے شدہ چھوڑنا یہاں تک کہ ایک بندش بندش کی طبی لاگت ظاہر کرے۔ حل: طبی نتیجے سے فی اہم خدمت دستیابی اور بحالی مقاصد طے کریں، اور ہدف تک خرچ کریں۔
• دباؤ کے تحت بڑا-دھماکہ وراثتی متبادل۔ جدیدیت مؤخر کرنا یہاں تک کہ ناکامی ایک جلدباز، مکمل کٹ اوور مجبور کرے۔ حل: متبادل کی منصوبہ بندی کریں جبکہ موجودہ کھلاڑی کام کرتا ہے، اور متوازی چلانے اور تصدیق شدہ ڈیٹا کے ساتھ تدریجی طور پر منتقل ہوں۔
• قدر نظم و ضبط سے باہر سافٹ ویئر۔ IT پروگراموں کو اس جانچ سے بچنے دینا جو دواؤں اور خدمات پر لاگو ہوتی ہے۔ حل: وہی قواعد — بیان کردہ فائدہ، حقیقی موازنہ کنندہ، استطاعت پروفائل، نفاذ-کے-بعد جائزہ۔

پختگی ماڈل

چیک لسٹ

• ہر سافٹ ویئر فیصلے کو اس کی حقیقت پسندانہ زندگی بھر ملکیت کی کل لاگت پر جانچیں، ہر دہرائی جانے والی لائن کے لیے نام زد بجٹ کے ساتھ۔
• ایک تکنیکی-قرض رجسٹر برقرار رکھیں، اسے اقتصادی شرائط میں رپورٹ کریں، اور ادائیگی کے لیے مستقل انجینئرنگ صلاحیت عہد کریں۔
• دیکھ بھال کو اصل کاروباری کیس سے آگے ایک منصوبہ بند آپریٹنگ لاگت کے طور پر مالی معاون کریں۔
• معاہدوں میں خریداری پر ڈیٹا-ایکسپورٹ حقوق، معیاری انٹرفیس، اور خروج مدد گفت و شنید کریں۔
• ہر بڑے نظام سے خروج کی قیمت سالانہ لگائیں، اور تجدیدات سے پہلے ایک لاگت شدہ متبادل زندہ رکھیں۔
• خریداری کی ایک شرط کے طور پر تصدیق شدہ کھلے-معیارات تعمیل (مثلاً FHIR) کا مطالبہ کریں۔
• بنانا-بمقابلہ-خریدنا ایک پورٹ فولیو کے طور پر فیصلہ کریں، اور بغیر ایک مالی معاون پوری-زندگی استحکام منصوبے کے کوئی تعمیر شروع نہ کریں۔
• اوپن-سورس آپشنز کو ملکیت کی کل لاگت پر جانچیں، ہوسٹنگ، حمایت، اور نگہبانی کا بجٹ رکھتے ہوئے۔
• طبی نتیجے سے فی اہم خدمت دستیابی اور بحالی اہداف طے کریں، اور خرچ کو ان سے ملائیں۔
• موجودہ کھلاڑیوں کے کام کرتے ہوئے وراثتی متبادل کا شیڈول بنائیں، بڑے-دھماکے کٹ اوور پر تدریجی منتقلی کو ترجیح دیتے ہوئے۔
• ڈیٹا منتقلی جلد لاگت اور جانچیں، اور ہر نظام کی زندگی بھر مریض ڈیٹا ایکسپورٹ کے قابل رکھیں۔
• سافٹ ویئر پروگراموں کو کسی بھی دوسری صحت سرمایہ کاری کی طرح اسی قدر جانچ سے گزاریں، نفاذ-کے-بعد جائزے کے ساتھ۔

Key sources

• WHO, Global Strategy on Digital Health 2020–2025 — the World Health Organization's frame for digital health investment, including sustainability and interoperability principles.
• HL7 International — the FHIR (Fast Healthcare Interoperability Resources) standard, the dominant open standard for health-data exchange.
• openEHR, DHIS2, and OpenMRS — open-source health-information platforms and specifications widely deployed worldwide, exemplars of community-sustained health software.
• U.S. Office of the National Coordinator for Health IT (now ASTP) — 21st Century Cures Act information-blocking and interoperability rules, a regulatory response to under-supplied interoperability.
• DORA, Accelerate State of DevOps reports — long-running research linking software delivery and reliability practices to organizational performance.
• UK National Audit Office — reports on the National Programme for IT in the NHS, the canonical case study of large-scale health-IT programme failure.

References

1. Software engineering — Wikipedia — https://en.wikipedia.org/wiki/Software_engineering
2. Software maintenance — Wikipedia — https://en.wikipedia.org/wiki/Software_maintenance
3. Total cost of ownership — Wikipedia — https://en.wikipedia.org/wiki/Total_cost_of_ownership
4. Technical debt — Wikipedia — https://en.wikipedia.org/wiki/Technical_debt
5. Legacy system — Wikipedia — https://en.wikipedia.org/wiki/Legacy_system
6. Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
7. Interoperability — Wikipedia — https://en.wikipedia.org/wiki/Interoperability
8. Network effect — Wikipedia — https://en.wikipedia.org/wiki/Network_effect
9. Fast Healthcare Interoperability Resources — Wikipedia — https://en.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources
10. Health Level 7 — Wikipedia — https://en.wikipedia.org/wiki/Health_Level_7
11. Open-source software — Wikipedia — https://en.wikipedia.org/wiki/Open-source_software
12. Site reliability engineering — Wikipedia — https://en.wikipedia.org/wiki/Site_reliability_engineering
13. World Health Organization — Global Strategy on Digital Health 2020–2025 — https://www.who.int/publications/i/item/9789240020924
14. HL7 International — FHIR specification — https://hl7.org/fhir/
15. National Audit Office — The National Programme for IT in the NHS: an update on the delivery of detailed care records systems — https://www.nao.org.uk/reports/the-national-programme-for-it-in-the-nhs-an-update-on-the-delivery-of-detailed-care-records-systems/
16. National Programme for IT — Wikipedia — https://en.wikipedia.org/wiki/National_Programme_for_IT