موضوع 1.1 — آپریٹنگ ماڈل

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

یہ صحت اور نگہداشت میں کیوں اہم ہے#

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

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

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

آپریٹنگ ماڈل کی پرتیں۔ ایک مفید TOM ایک ڈھیر ہے، جس میں ہر پرت اپنے اوپر والی کی خدمت کرتی ہے:

• حکمت عملی اور نتائج — آبادی اور خدمت کے وہ ناپے جا سکنے والے نتائج جنہیں بہتر بنانے کے لیے آپ موجود ہیں (اکثر OKRs کے طور پر ظاہر؛ دیکھیے موضوع 1.3 — شواہد پر مبنی فیصلے)۔
• قدر کے بہاؤ — وہ سرے سے سرے تک کے بہاؤ جو صارف کو قدر پہنچاتے ہیں، مثلاً "مریض کو ریفر کریں، درجہ بندی کریں اور علاج کریں" — ادارے کے خاکے کے بجائے شہری کے سفر کے گرد منظم۔
• صلاحیتیں — وہ چیزیں جو آپ کو کرنے کے قابل ہونا چاہییں (شناخت، ملاقات کی بکنگ، طبی دستاویزات، تجزیات)۔ حل بدلنے کے باوجود صلاحیتیں مستحکم رہتی ہیں۔
• ٹیمیں — صلاحیتوں اور قدر کے بہاؤ کی ترسیل کے لیے منظم لوگ (دیکھیے نیچے Team Topologies)۔
• نظامت اور فیصلے کے اختیارات — کون کیا طے کرتا ہے، اور یقین دہانی کیسے لاگو ہوتی ہے۔
• ٹیکنالوجی اور ڈیٹا — وہ پلیٹ فارم، معیارات اور ڈیٹا کا فن تعمیر جن پر ٹیمیں تعمیر کرتی ہیں۔
• سپلائرز — وہ منڈی جس سے آپ خریدتے ہیں اور اس کا انتظام کیسے کرتے ہیں۔

اوپر سے نیچے ڈیزائن کرنا (حکمت عملی ← قدر کے بہاؤ ← صلاحیتیں) ٹیموں اور ٹیکنالوجی کو پرانے ڈھانچوں کے بجائے نتائج سے ہم آہنگ رکھتا ہے۔

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

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

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

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

بہترین طریقے#

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

2. پلیٹ فارم جمع وفاق کی شکل اپنائیں۔ مشترکہ صلاحیتیں مرکزی طور پر خود خدمتی پلیٹ فارم کے طور پر فراہم کریں، اور ٹرسٹس اور علاقوں کی بہاؤ سے ہم آہنگ ٹیموں کو ان کے اوپر تعمیر کرنے دیں۔ یہ آپ کو تحفظ اور باہمی عملیت پر قومی یکسانیت اور مقامی رفتار و ملکیت دیتا ہے — وہ صلح جو یہ شعبہ مانگتا ہے۔

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

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

5. RACI یا RAPID نقشے سے فیصلے کے اختیارات صریح کریں۔ مبہم اختیار رکی ہوئی ترسیل کی سب سے عام وجہ ہے۔ ہر اہم فیصلے کی قسم کے لیے نام لیں کہ کون ذمہ دار/جواب دہ/مشاورت شدہ/مطلع (RACI) ہے، یا کون سفارش کرتا ہے، متفق ہوتا ہے، انجام دیتا ہے، رائے دیتا ہے، اور فیصلہ کرتا ہے (RAPID)۔ اسے شائع کریں تاکہ ٹیمیں وہ فیصلے بالا افسران کو بھیجنا بند کریں جو کرنے کا انہیں اختیار ہے۔

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

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

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

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

اپنی ٹیم کے ساتھ زیرِ بحث لانے کے سوالات#

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

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

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

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

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

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

عملی مثال: صحت اور نگہداشت کی ایک مثال#

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

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

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

شعبہ جاتی زاویے#

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

اسٹارٹ اپ#

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

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

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

بڑا ادارہ#

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

حکومت#

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

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

• ادارے کے خاکے کو خودکار بنانا۔ ٹیموں کو قدر کے بہاؤ کے بجائے موجودہ محکموں کے گرد ڈیزائن کرنا، تاکہ TOM جزیروں کو پختہ کر دے۔ تدارک: نتائج اور قدر کے بہاؤ سے نیچے کی طرف ڈیزائن کریں۔
• پلیٹ فارم جو رکاوٹ بن جائے۔ حد سے زیادہ وسیع مرکزی پلیٹ فارم ٹیم جس کے پیچھے ہر درخواست قطار میں کھڑی ہو۔ تدارک: کم از کم قابلِ عمل پلیٹ فارم، جسے SLAs والی مصنوعہ سمجھا جائے۔
• مصنوعات کے کام کے لیے منصوبے کی فنڈنگ۔ ختم ہونے والی رقم منتشر کر کے دوبارہ بنانے کا چکر مجبور کرتی ہے۔ تدارک: مرحلہ وار دروازوں کے ساتھ مستقل مصنوعات کی فنڈنگ۔
• تبدیلی کو کھلانے کے لیے چلانے کو بھوکا رکھنا۔ لائیو خدمات کے آپریشنز کو اس وقت تک کم فنڈ دینا جب تک طبی نظام بگڑ نہ جائیں۔ تدارک: چلانے اور تبدیلی کو صریح فنڈ کریں اور چلانے کا بجٹ محفوظ رکھیں۔
• بے مالک فیصلے۔ کوئی نہیں جانتا کون طے کرتا ہے، اس لیے سب کچھ بالا افسران کو جاتا ہے۔ تدارک: شائع شدہ RACI/RAPID۔
• طے شدہ طور پر پابندی۔ بنیادی طبی ڈیٹا ملکیتی سپلائر نظام میں اخراج کے بغیر پھنسا ہوا۔ تدارک: ہر اسٹریٹجک معاہدے میں کھلے معیارات اور اخراج کے حقوق۔

پختگی کا ماڈل#

جانچ فہرست#

• آپریٹنگ ماڈل نتائج اور قدر کے بہاؤ سے ڈیزائن کیا گیا ہے، موجودہ درجہ بندی سے نہیں۔
• مشترکہ صلاحیتیں کم از کم قابلِ عمل پلیٹ فارم کے طور پر فراہم کی جاتی ہیں، بہاؤ والی ٹیمیں اس کے اوپر تعمیر کرتی ہیں۔
• مصنوعاتی ٹیمیں مستقل فنڈ شدہ اور قدر کے بہاؤ سے ہم آہنگ ہیں۔
• اخراجات کا کنٹرول مرحلہ وار (دریافت/الفا/بیٹا/لائیو دروازے) اور خطرے اور قدر کے متناسب ہے۔
• فیصلے کے اختیارات دستاویزی (RACI یا RAPID) اور شائع شدہ ہیں۔
• چلانا اور تبدیلی صریح فنڈ کیے گئے ہیں، چلانے کا بجٹ محفوظ ہے۔
• ٹیموں کی اقسام (بہاؤ سے ہم آہنگ، پلیٹ فارم، معاون، پیچیدہ ذیلی نظام) سمجھی اور استعمال کی جاتی ہیں۔
• بنانا/خریدنا ہر صلاحیت کے لیے سوچا سمجھا انتخاب ہے؛ بنیادی طبی ڈیٹا پابندی سے بچا ہوا ہے۔
• معاہدے کھلے معیارات (مثلاً HL7 FHIR، SNOMED CT) اور اخراج کے حقوق کا تقاضا کرتے ہیں۔

کلیدی ماخذ#

• میتھیو اسکیلٹن اور مینوئل پیس — Team Topologies (بہاؤ سے ہم آہنگ، پلیٹ فارم، معاون اور پیچیدہ ذیلی نظام ٹیمیں؛ کم از کم قابلِ عمل پلیٹ فارم)۔
• GOV.UK سروس مینوئل — اخراجات کے کنٹرول اور مرحلہ وار یقین دہانی (دریافت/الفا/بیٹا/لائیو)؛ گورنمنٹ ڈیجیٹل سروس۔
• NHS ڈیجیٹل سروس مینوئل — NHS سروس اسٹینڈرڈ (service-manual.nhs.uk)۔
• AXELOS — پورٹ فولیو اور پروگرام کی نظامت کے لیے Management of Portfolios (MoP) اور Managing Successful Programmes (MSP)۔
• بین اینڈ کمپنی — RAPID فیصلے کے اختیارات کا فریم ورک؛ اور RACI ذمہ داری تفویض کرنے کا ماڈل۔
• جان ڈوئر — نتائج کی تعریف کے لیے Measure What Matters (OKRs)۔

حوالہ جات#

1. Operating model — Wikipedia — https://en.wikipedia.org/wiki/Operating_model
2. Value stream — Wikipedia — https://en.wikipedia.org/wiki/Value_stream
3. Objectives and key results (OKRs) — Wikipedia — https://en.wikipedia.org/wiki/Objectives_and_key_results
4. Responsibility assignment matrix (RACI) — Wikipedia — https://en.wikipedia.org/wiki/Responsibility_assignment_matrix
5. Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
6. Government Digital Service — Wikipedia — https://en.wikipedia.org/wiki/Government_Digital_Service
7. Fast Healthcare Interoperability Resources (HL7 FHIR) — Wikipedia — https://en.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources
8. SNOMED CT — Wikipedia — https://en.wikipedia.org/wiki/SNOMED_CT
9. Team Topologies: Organizing Business and Technology Teams for Fast Flow — Matthew Skelton & Manuel Pais, IT Revolution — https://teamtopologies.com/book
10. Spend controls and staged assurance (discovery/alpha/beta/live) — GOV.UK Service Manual, Government Digital Service — https://www.gov.uk/service-manual/agile-delivery
11. NHS service standard — NHS digital service manual, NHS England — https://service-manual.nhs.uk/standards-and-technology/service-standard
12. Managing Successful Programmes (MSP) and Management of Portfolios (MoP) — AXELOS/PeopleCert — https://www.axelos.com/
13. Measure What Matters (OKRs) — John Doerr — https://www.whatmatters.com/the-book