विषय 1.1 — संचालन मॉडल

एक वाक्य में: एक लक्ष्य संचालन मॉडल (TOM) यह सोच-समझकर डिज़ाइन करना है कि आपके संगठन की रणनीति मूल्य धाराओं, क्षमताओं, टीमों, प्रशासन, प्रौद्योगिकी, डेटा, और आपूर्तिकर्ताओं के माध्यम से डिजिटल स्वास्थ्य और देखभाल परिणाम देने के लिए कैसे प्रवाहित होती है — और उसका आकार सही पाना यह निर्धारित करता है कि नीचे की हर चीज़ तेज़ और सुरक्षित है या धीमी और भंगुर।

यह स्वास्थ्य और देखभाल में क्यों महत्वपूर्ण है#

अधिकांश डिजिटल स्वास्थ्य संगठन प्रतिभा या प्रौद्योगिकी की कमी से विफल नहीं होते; वे इसलिए विफल होते हैं क्योंकि उनका संचालन मॉडल उनके विरुद्ध लड़ता है। वित्तपोषण समय-सीमित परियोजनाओं से बंधा होता है, निर्णय अधिकार अस्पष्ट होते हैं, और हर टीम वही लॉगिन, एकीकरण, और ऑडिट प्लंबिंग फिर से बनाती है। परिणाम सार्वजनिक धन पर दोहराई गई लागत है, असंगत क्लिनिकल सुरक्षा है, और ऐसी सेवाएं हैं जो एक एकीकृत देखभाल प्रणाली (ICS) में डेटा साझा नहीं कर सकतीं।

इस क्षेत्र में एक संचालन मॉडल विशिष्ट है क्योंकि इसे प्रतिस्पर्धी अच्छाइयों को समेटना होता है। इसे संप्रभु संगठनों — ट्रस्ट, स्थानीय अधिकारियों, GP प्रैक्टिस — की स्वायत्तता का सम्मान करने के लिए पर्याप्त रूप से संघीय होना चाहिए, फिर भी उनमें एक रोगी को एक सुरक्षित अनुभव देने के लिए पर्याप्त रूप से सुसंगत होना चाहिए। इसे संचालन (क्लिनिकल सिस्टम को सुरक्षित रूप से उपलब्ध रखना) को परिवर्तन (उन्हें बेहतर बनाना) के मुक़ाबले संतुलित करना चाहिए, जब डाउनटाइम देखभाल को प्रभावित कर सकता है। और इसे आनुपातिक रूप से खर्च करना चाहिए: सार्वजनिक जवाबदेही और क्लिनिकल सुरक्षा के लिए पर्याप्त भारी आश्वासन, पुनरावृत्ति का गला न घोंटने के लिए पर्याप्त हल्का। TOM वह जगह है जहां उन समझौतों को दुर्घटनावश छोड़ने के बजाय स्पष्ट किया जाता है।

मुख्य अवधारणाएं#

संचालन मॉडल की परतें। एक उपयोगी TOM एक स्टैक है, हर परत उससे ऊपर वाली की सेवा करती है:

• रणनीति और परिणाम — मापने योग्य जनसंख्या और सेवा परिणाम जिन्हें बेहतर बनाने के लिए आप अस्तित्व में हैं (अक्सर OKRs के रूप में व्यक्त; देखें विषय 1.3 — साक्ष्य-आधारित निर्णय)।
• मूल्य धाराएं — एंड-टू-एंड प्रवाह जो एक उपयोगकर्ता को मूल्य देते हैं, जैसे "एक रोगी को रेफर करें, त्रिआज करें, और उपचार करें" — नागरिक की यात्रा के आसपास व्यवस्थित, संगठन चार्ट के आसपास नहीं।
• क्षमताएं — वे चीज़ें जो आपको करने में सक्षम होना चाहिए (पहचान, अपॉइंटमेंट बुकिंग, क्लिनिकल दस्तावेज़ीकरण, विश्लेषिकी)। समाधान बदलने पर भी क्षमताएं स्थिर रहती हैं।
• टीमें — क्षमताओं और मूल्य धाराओं को देने के लिए व्यवस्थित लोग (नीचे Team Topologies देखें)।
• प्रशासन और निर्णय अधिकार — कौन क्या तय करता है, और आश्वासन कैसे लागू किया जाता है।
• प्रौद्योगिकी और डेटा — प्लेटफ़ॉर्म, मानक, और डेटा आर्किटेक्चर जिन पर टीमें निर्माण करती हैं।
• आपूर्तिकर्ता — वह बाज़ार जिससे आप खरीदते हैं और आप उसका प्रबंधन कैसे करते हैं।

ऊपर से नीचे डिज़ाइन करना (रणनीति → मूल्य धाराएं → क्षमताएं) टीमों और प्रौद्योगिकी को विरासत संरचनाओं के बजाय परिणामों के साथ संरेखित रखता है।

केंद्रीकृत बनाम संघीय बनाम प्लेटफ़ॉर्म मॉडल। एक केंद्रीकृत मॉडल डिलीवरी को एक टीम या आर्म्स-लेंथ निकाय में केंद्रित करता है: मानकीकृत करने में सुसंगत और सस्ता, लेकिन एक अड़चन और अक्सर स्थानीय आवश्यकता से दूर। एक संघीय मॉडल डिलीवरी को ट्रस्ट और स्थानों को सौंपता है: उत्तरदायी और स्थानीय रूप से स्वामित्व वाला, लेकिन दोहराव और विचलन की प्रवृत्ति वाला। एक प्लेटफ़ॉर्म मॉडल समेटने वाला पैटर्न है: एक केंद्रीय टीम साझा, पुनः उपयोग करने योग्य क्षमताएं (पहचान, अंतरसंचालनीयता, होस्टिंग, डिज़ाइन सिस्टम) एक प्लेटफ़ॉर्म के रूप में प्रदान करती है, और संघीय टीमें उसके ऊपर तेज़ी से निर्माण करती हैं। अधिकांश परिपक्व स्वास्थ्य प्रणालियां "प्लेटफ़ॉर्म प्लस संघवाद" पर अभिसरित होती हैं।

Team Topologies। यह ढांचा चार टीम प्रकारों को नाम देता है — स्ट्रीम-संरेखित (एक मूल्य धारा का स्वामित्व), प्लेटफ़ॉर्म (स्व-सेवा क्षमताएं प्रदान करना), सक्षम बनाना (दूसरों को एक क्षमता में कोचिंग देना), और जटिल-उपप्रणाली (एल्गोरिथम जैसा गहरा विशेषज्ञ कार्य) — और उनके बीच कम-घर्षण वाली बातचीत पर ज़ोर देता है। यह प्लेटफ़ॉर्म मॉडल पर स्पष्ट रूप से मैप करता है: प्लेटफ़ॉर्म टीमें स्ट्रीम-संरेखित टीमों पर संज्ञानात्मक भार कम करती हैं ताकि वे उपयोगकर्ता और क्लिनिकल मूल्य पर ध्यान केंद्रित कर सकें।

संचालन बनाम परिवर्तन। संचालन लाइव सेवाओं को सुरक्षित और उपलब्ध रखना है; परिवर्तन उन्हें बेहतर बनाना या बनाना है। उत्पाद टीमें जो एक सेवा को बनाती और चलाती दोनों हैं ("आप इसे बनाते हैं, आप इसे चलाते हैं") फीडबैक लूप को बंद करती हैं और सुरक्षा को बेहतर बनाती हैं, लेकिन संतुलन को ईमानदारी से वित्तपोषित किया जाना चाहिए — परिवर्तन को वित्तपोषित करने के लिए संचालन को भूखा रखना ही वह तरीका है जिससे क्लिनिकल सिस्टम खराब होते हैं।

सबसे पतला व्यावहार्य प्लेटफ़ॉर्म (TVP)। Team Topologies से: एक प्लेटफ़ॉर्म साझा सेवाओं का सबसे छोटा समूह होना चाहिए जो वास्तव में स्ट्रीम टीमों के लिए घर्षण कम करता है — इससे अधिक नहीं। एक अत्यधिक-निर्मित प्लेटफ़ॉर्म अपनी खुद की अड़चन और अपनी खुद की विरासत बन जाता है। कुछ क्षमताओं से शुरू करें जिनकी हर टीम को वास्तव में आवश्यकता है (प्रमाणीकरण, एक अंतरसंचालनीयता परत, होस्टिंग, एक डिज़ाइन सिस्टम) और केवल प्रमाणित मांग पर बढ़ें।

सर्वोत्तम प्रथाएं#

1. मॉडल को परिणामों से नीचे की ओर डिज़ाइन करें, संगठन चार्ट से ऊपर की ओर नहीं। उन जनसंख्या और सेवा परिणामों से शुरू करें जिन्हें आपको आगे बढ़ाना है, उन्हें देने वाली मूल्य धाराएं निकालें, और तभी टीमों और प्रौद्योगिकी को डिज़ाइन करें। मौजूदा पदानुक्रम में लंगर डाला गया एक TOM बस वर्तमान साइलो को स्वचालित करता है।

2. प्लेटफ़ॉर्म-प्लस-संघवाद आकार अपनाएं। साझा क्षमताओं को केंद्रीय रूप से एक स्व-सेवा प्लेटफ़ॉर्म के रूप में प्रदान करें, और ट्रस्ट और स्थानों में स्ट्रीम-संरेखित टीमों को उसके ऊपर निर्माण करने दें। यह आपको सुरक्षा और अंतरसंचालनीयता पर राष्ट्रीय संगति स्थानीय गति और स्वामित्व के साथ देता है — वह समेलन जिसकी यह क्षेत्र मांग करता है।

3. परियोजनाओं को नहीं, उत्पादों को वित्तपोषित करें। पैसे को समय-सीमित परियोजनाओं से मूल्य धाराओं के साथ संरेखित लगातार वित्तपोषित उत्पाद टीमों में ले जाएं। परियोजना वित्तपोषण टीमों को ठीक उसी बिंदु पर भंग होने के लिए मजबूर करता है जहां उन्होंने डोमेन सीखा है; उत्पाद वित्तपोषण उस सुरक्षा ज्ञान और पुनरावृत्ति को बनाए रखता है जिसकी स्वास्थ्य सेवाओं को आवश्यकता है (देखें विषय 5.0 — उत्पाद-नेतृत्व वाला कार्य)।

4. व्यय नियंत्रण को आनुपातिक और चरणबद्ध बनाएं। साक्ष्य से जुड़ा चरणबद्ध वित्तपोषण उपयोग करें — पूरे कार्यक्रम को पहले से मंज़ूर करने के बजाय डिस्कवरी, अल्फा, बीटा, और लाइव द्वारों पर पैसा जारी करें। GDS-शैली के व्यय नियंत्रण और NHS आश्वासन मार्ग अप्रमाणित विचारों पर बड़ी डूबी हुई लागतों को रोकने के लिए मौजूद हैं; उन्हें जोखिम और मूल्य के अनुसार मापी गई सीमाओं के रूप में लागू करें, सर्वव्यापी नौकरशाही के रूप में नहीं।

5. RACI या RAPID मानचित्र के साथ निर्णय अधिकारों को स्पष्ट बनाएं। अस्पष्ट अधिकार रुकी हुई डिलीवरी का सबसे आम कारण है। हर महत्वपूर्ण निर्णय प्रकार के लिए नाम दें कि कौन Responsible/Accountable/Consulted/Informed है (RACI) या कौन Recommends, Agrees, Performs, Input देता है, और Decides करता है (RAPID)। इसे प्रकाशित करें ताकि टीमें उन निर्णयों को आगे बढ़ाना बंद करें जो लेने के लिए वे सशक्त हैं।

6. प्लेटफ़ॉर्म को पतला और मांग-नेतृत्व वाला रखें। साझा क्षमताएं केवल तभी बनाएं जब दो या अधिक टीमों को प्रमाणित रूप से एक ही चीज़ की आवश्यकता हो, और प्लेटफ़ॉर्म को अपने स्वयं के उपयोगकर्ताओं (आंतरिक टीमों) वाले एक उत्पाद के रूप में मानें। एक भव्य प्लेटफ़ॉर्म को पहले से बनाने की इच्छा का विरोध करें; सबसे पतला व्यावहार्य प्लेटफ़ॉर्म अपनाने के माध्यम से अपना दायरा अर्जित करता है।

7. आपूर्तिकर्ताओं को मॉडल के भाग के रूप में प्रबंधित करें, उसके बाहर नहीं। सोच-समझकर तय करें कि कौन सी क्षमताएं रणनीतिक हैं (बनाएं/स्वामित्व करें) और कौन सी सामान्य वस्तु हैं (खरीदें), मुख्य क्लिनिकल डेटा पर एकल-आपूर्तिकर्ता लॉक-इन से बचें, और अनुबंधों में खुले मानकों और निकास अधिकारों की मांग करें। आपके आपूर्तिकर्ता आपके संचालन मॉडल की एक परत हैं, और उनके काम करने के तरीके आपके साथ संगत होने चाहिए।

8. निर्णय अधिकारों को स्पष्ट बनाएं। एक संचालन मॉडल तभी काम करता है जब लोगों को पता हो कि कौन क्या तय करता है — कौन से विकल्प एक उत्पाद टीम के पास हैं, कौन से एक क्लिनिकल-सुरक्षा प्राधिकरण के पास, और कौन से एक बोर्ड तक पहुंचने चाहिए। निर्णय अधिकारों को मैप करें और हर निर्णय को उस सबसे निचले स्तर तक धकेलें जो उसे सुरक्षित रूप से संभाल सके, ताकि डिलीवरी अनावश्यक वृद्धि से बाधित न हो। अस्पष्ट अधिकार धीमी, रक्षात्मक डिलीवरी के सबसे आम कारणों में से एक है।

9. संचालन मॉडल को एक उत्पाद के रूप में मानें जिसे आप विकसित करते हैं। एक लक्ष्य संचालन मॉडल एक बार सेट नहीं किया जाता और दीवार पर फ्रेम नहीं किया जाता; जैसे मांग, प्रौद्योगिकी और साझेदारी बदलती है वैसे इसका निरीक्षण करें, और साक्ष्य के आधार पर इसे अनुकूलित करें। कुछ संकेतों पर नज़र रखें — कार्य का प्रवाह, निर्णय-का-समय, पुनः कार्य, और टीम स्वास्थ्य — और संरचनाओं को तब बदलें जब वे प्रमाणित रूप से बाधा बन रही हों, पुनर्गठन के फैशन के जवाब में नहीं।

आपकी टीम के साथ चर्चा करने के लिए प्रश्न#

1. क्या हमारा संचालन मॉडल परिणामों और मूल्य धाराओं से नीचे की ओर डिज़ाइन किया गया है, या इसने बस हमारे मौजूदा संगठन चार्ट और उसके साइलो को स्वचालित कर दिया है? यह प्रश्न विषय की केंद्रीय चेतावनी की ओर जाता है कि वर्तमान पदानुक्रम में लंगर डाला गया एक TOM बस उन साइलो को गहरा करता है जो आपके पास पहले से हैं, इसलिए किसी भी पुनर्गठन से पहले इसे मेज़ पर रखने लायक है। यह एक स्वास्थ्य और देखभाल सेटिंग में मायने रखता है क्योंकि मूल्य धाराएं संप्रभु संगठनों में नागरिक की यात्रा — रेफर, त्रिआज, उपचार — का अनुसरण करती हैं, जबकि संगठन चार्ट संस्थागत सीमाओं का अनुसरण करते हैं, और बाद वाले पर बना एक मॉडल सार्वजनिक धन पर खंडित, गैर-अंतरसंचालनीय सेवाएं उत्पन्न करता रहेगा। ईमानदारी से बहस करने योग्य तनाव यह है कि परिणामों से ऊपर से नीचे डिज़ाइन करना वास्तव में विघटनकारी है: यह विभागीय स्वामित्व, बजट, और रिपोर्टिंग लाइनों को काटता है जिनके आसपास वरिष्ठ लोगों ने करियर बनाए हैं, इसलिए इसे ठीक से करने की वास्तविक राजनीतिक कीमत है। अपने शीर्ष तीन परिणामों को नाम देकर और यह जांचकर स्वयं को ठोस रूप से परखें कि क्या आपकी वास्तविक टीम सीमाएं और वित्तपोषण लाइनें उन मूल्य धाराओं का अनुसरण करती हैं या विभागों का; यदि टीमें विभागों पर स्पष्ट रूप से मैप करती हैं, तो वही आपका उत्तर है। एक अच्छा, ईमानदार उत्तर स्वीकार करता है कि मॉडल कहां संगठन-चार्ट-आकार का है, कम से कम एक मूल्य धारा की पहचान करता है जो वर्तमान में उसके नुकसान के लिए साइलो में विभाजित है, और इस बारे में यथार्थवादी है कि संगठन कौन सी संरचनात्मक सीमाएं फिर से खींचने को तैयार है।

2. हमारे सबसे पतले व्यावहार्य प्लेटफ़ॉर्म में क्या शामिल होना चाहिए, और हम इसे या तो एक अड़चन में अत्यधिक-निर्मित होने या इतना कम-निर्मित होने से कैसे रोकेंगे कि हर टीम उसी प्लंबिंग को फिर से बनाए? प्लेटफ़ॉर्म-प्लस-संघवाद आकार तभी काम करता है जब प्लेटफ़ॉर्म पतला और मांग-नेतृत्व वाला रहे, और यह प्रश्न टीम को विषय द्वारा नाम दी गई दोनों विफलता विधाओं का सामना कराता है — भव्य प्लेटफ़ॉर्म जो अपनी खुद की विरासत अड़चन बन जाता है, और अनुपस्थिति जो हर टीम को लॉगिन, एकीकरण, और ऑडिट फिर से बनाने के लिए मजबूर करती है। यह मायने रखता है क्योंकि एक ICS में प्लेटफ़ॉर्म प्रभावी रूप से साझा बुनियादी ढांचा है (पहचान, एक FHIR अंतरसंचालनीयता परत, सुरक्षा आधार रेखाओं के साथ होस्टिंग, एक डिज़ाइन सिस्टम) और उसके दायरे को गलत करना हर स्ट्रीम टीम में या तो लागत या घर्षण को गुणा करता है। बहस करने योग्य समझौता समय और साक्ष्य का है: बहुत जल्दी बनाएं और आप गलत अनुमान लगाते हैं और एक अड़चन बनाते हैं; बहुत देर से बनाएं और दोहराव पहले ही जड़ जमा चुका होता है — इसलिए "दो या अधिक टीमों को प्रमाणित रूप से एक ही चीज़ की आवश्यकता है" परीक्षण मुख्य बिंदु है, और टीम को तनाव-परीक्षण करना चाहिए कि क्या वे वास्तव में इसे लागू करते हैं या बस वह बनाते हैं जो स्पष्ट रूप से केंद्रीय लगता है। देखें कि आप वर्तमान में प्लेटफ़ॉर्म के रूप में क्या मानते हैं बनाम टीमें क्या फिर से बनाती हैं, और पूछें कि क्या प्लेटफ़ॉर्म को अपने स्वयं के आंतरिक उपयोगकर्ताओं और SLA वाले उत्पाद के रूप में चलाया जाता है या हर कोई जिसके पीछे प्रतीक्षा करता है ऐसी एक कतार के रूप में। एक ईमानदार उत्तर उन विशिष्ट क्षमताओं को नाम देता है जो आज दो-टीम परीक्षण पास करती हैं, बाकी को पहले से बनाने के प्रलोभन का विरोध करता है, और प्लेटफ़ॉर्म टीम के आंतरिक उपयोगकर्ताओं को वास्तविक सेवा स्तरों वाले वास्तविक ग्राहकों के रूप में मानने के लिए प्रतिबद्ध होता है।

3. हमारे निर्णय अधिकार वास्तव में कहां अस्पष्ट हैं, और टीमें आज क्या आगे बढ़ा रही हैं जिसे उन्हें स्वयं तय करने के लिए सशक्त होना चाहिए? अस्पष्ट अधिकार को रुकी हुई डिलीवरी का सबसे आम कारण कहा गया है, इसलिए यह प्रश्न उस रोज़मर्रा के घर्षण को सामने लाता है जिसे एक प्रकाशित RACI या RAPID मानचित्र हटाने वाला है। यह एक संघीय स्वास्थ्य प्रणाली में तीव्रता से मायने रखता है जहां स्थान टीमों, एक ICS डिजिटल बोर्ड, क्लिनिकल सुरक्षा, और सूचना प्रशासन सभी का एक निर्णय पर वैध दावा है, और अस्पष्ट सीमाओं का अर्थ है या तो सब कुछ आगे बढ़ता है, या, बदतर, कोई भी किसी कॉल का स्वामित्व नहीं लेता जब तक वह गलत न हो जाए। बहस करने योग्य तनाव यह है कि निर्णयों को सौंपने के लिए सीमाओं के भीतर भरोसा करना आवश्यक है, जिसका वरिष्ठ नेता और बोर्ड अक्सर ठीक उन्हीं जगहों पर विरोध करते हैं जहां क्लिनिकल सुरक्षा या सार्वजनिक धन शामिल होता है — फिर भी उस भरोसे को रोकना ही वह है जो पहली जगह में वृद्धि की गतिरोध बनाता है। पिछले पांच निर्णयों को सूचीबद्ध करके इसे ठोस बनाएं जो आगे बढ़े और हर एक के लिए पूछें कि किसे तय करना चाहिए था और किस गार्डरेल ने उन्हें ऐसा करने दिया होता; पैटर्न आमतौर पर अस्पष्ट निर्णय प्रकारों की एक छोटी संख्या को प्रकट करता है। एक अच्छा उत्तर यह उत्पन्न करता है कि कौन क्या तय करता है इसका एक विशिष्ट, प्रकाशित करने योग्य विवरण — प्लेटफ़ॉर्म मानकों, सेवा डिज़ाइन, और क्लिनिकल-सुरक्षा हस्ताक्षर को अलग करते हुए — और इस बारे में ईमानदार है कि संगठन वास्तव में कौन से निर्णय सौंपने को तैयार है बनाम कौन से वह केंद्रीय रखेगा और क्यों।

4. क्या हम संचालन और परिवर्तन को ईमानदारी से वित्तपोषित कर रहे हैं, या हम चुपचाप नई सुविधाओं का भुगतान करने के लिए लाइव-सेवा संचालन को भूखा रख रहे हैं? विषय स्पष्ट है कि परिवर्तन को वित्तपोषित करने के लिए संचालन को भूखा रखना ही वह है जिससे क्लिनिकल सिस्टम खराब होते हैं, और यह प्रश्न किसी आउटेज या सुरक्षा घटना द्वारा आपके लिए यह निर्णय लेने से पहले संतुलन को खुले में मजबूर करता है। यह स्वास्थ्य और देखभाल में मायने रखता है क्योंकि "संचालन" कोई बैक-ऑफिस ओवरहेड नहीं है — यह उन सिस्टमों की उपलब्धता है जिन पर क्लिनिशियन देखभाल के बिंदु पर निर्भर होते हैं, इसलिए एक खराब संचालन बजट डाउनटाइम के रूप में दिखाई देता है जो रोगियों को प्रभावित कर सकता है, केवल असुविधाजनक उपयोगकर्ताओं को नहीं। समझौता असहज है क्योंकि परिवर्तन दृश्यमान और सराहा जाता है जबकि संचालन विफल होने तक अदृश्य रहता है, इसलिए बोर्ड और रोडमैप स्वाभाविक रूप से नए की ओर झुकते हैं; एक "आप इसे बनाते हैं, आप इसे चलाते हैं" मॉडल फीडबैक लूप को बंद रखकर मदद करता है, लेकिन केवल तभी जब टीम का संचालन समय वास्तव में सुरक्षित है, केवल नाममात्र आवंटित और फिर लूटा नहीं गया है। पिछली तिमाही में हर उत्पाद टीम की क्षमता का वास्तव में कितना हिस्सा सेवाओं को सुरक्षित और उपलब्ध रखने में गया बनाम क्या योजना बनाई गई थी, और क्या संचालन कार्य को ट्रैक और मूल्यवान माना जाता है या रुकावट के रूप में माना जाता है, यह देखकर इसे ठोस बनाएं। एक ईमानदार उत्तर नाम देता है कि आज संचालन कहां कम-वित्तपोषित है, एक यथार्थवादी संचालन आवंटन को अवशेष के बजाय पहले शुल्क के रूप में सुरक्षित करता है, और इस बारे में स्पष्ट है कि कौन सी लाइव सेवाएं संचित परिचालन जोखिम उठा रही हैं।

5. हम कौन सी क्षमताएं सोच-समझकर बनाने और स्वामित्व करने बनाम खरीदने का विकल्प चुन रहे हैं, और क्या हम बिना मतलब के अपने मुख्य क्लिनिकल डेटा पर लॉक-इन स्वीकार कर रहे हैं? यहां सर्वोत्तम प्रथा बनाम खरीद को सोच-समझकर तय करना है, मुख्य क्लिनिकल डेटा पर एकल-आपूर्तिकर्ता लॉक-इन से बचना है, और आपूर्तिकर्ताओं को संचालन मॉडल की एक परत के रूप में मानना है न कि उसके बाहर की कोई चीज़ — यह प्रश्न परखता है कि क्या वे विकल्प वास्तव में बनाए जा रहे हैं या डिफ़ॉल्ट हो रहे हैं। यह मायने रखता है क्योंकि डिजिटल स्वास्थ्य में सबसे परिणामी लॉक-इन क्लिनिकल रिकॉर्ड और उसके डेटा के आसपास है, जहां बिना किसी यथार्थवादी निकास के एक मालिकाना स्टोर एक पूरी प्रणाली को एक दशक के लिए फंसा सकता है और यह निर्धारित कर सकता है कि हर डाउनस्ट्रीम सेवा क्या कर सकती है। तनाव गति बनाम विकल्प का है: खरीदना तेज़ और अक्सर आज सस्ता है, खासकर एक तनावग्रस्त टीम के लिए, लेकिन खुले मानकों या निकास अधिकारों के बिना हर सुविधाजनक खरीद चुपचाप कल के विकल्पों को संकुचित करती है, और लागत तभी दिखाई देती है जब आप छोड़ने की कोशिश करते हैं। अपनी मुख्य क्षमताओं को सूचीबद्ध करके, हर एक को रणनीतिक (बनाएं/स्वामित्व करें) या सामान्य वस्तु (खरीदें) के रूप में चिह्नित करके, और यह जांचकर कि क्या सामान्य वस्तु वाले के पीछे के अनुबंध वास्तव में खुले मानकों (HL7 FHIR, SNOMED CT) और लागू करने योग्य निकास अधिकारों की मांग करते हैं, इसे ठोस बनाएं। एक अच्छा उत्तर कुछ वास्तव में रणनीतिक क्षमताओं को कई सुरक्षित रूप से खरीदी गई क्षमताओं से अलग करता है, इस बारे में ईमानदार है कि संगठन क्लिनिकल डेटा पर पहले से कहां लॉक-इन है, और सबसे महत्वपूर्ण अनुबंधों में खुले मानकों और निकास अधिकारों के लिए प्रतिबद्ध होता है।

6. हमें कैसे पता चलेगा कि हमारे संचालन मॉडल को बदलने की आवश्यकता कब है, और फैशन पर या एक नए नेता के आगमन पर पुनर्गठन करने के बजाय कौन से संकेत हमें बताएंगे? विषय संचालन मॉडल को दीवार पर फ्रेम किए गए आरेख के बजाय एक उत्पाद के रूप में तैयार करता है जिसे आप साक्ष्य पर विकसित करते हैं, इसलिए यह प्रश्न टीम से पहले से यह परिभाषित करने के लिए कहता है कि कौन सा साक्ष्य इसे फिर से आकार देने को उचित ठहराएगा। यह स्वास्थ्य और देखभाल में मायने रखता है क्योंकि पुनर्गठन विघटनकारी और महंगा है — यह कड़ी मेहनत से अर्जित डोमेन और क्लिनिकल-सुरक्षा ज्ञान को भंग करता है — फिर भी यह क्षेत्र नीति चक्रों और नई नियुक्तियों द्वारा संचालित संरचनात्मक उथल-पुथल की प्रवृत्ति रखता है न कि इस बात से कि क्या वर्तमान मॉडल वास्तव में बाधा बन रहा है। तनाव स्थिरता और अनुकूलन के बीच है: मॉडल को बहुत आसानी से बदलें और आप टीमों को कभी बसने या सुरक्षा विशेषज्ञता अर्जित करने नहीं देते, इसे बहुत कम बदलें और जमी हुई संरचनाएं तब तक प्रवाह को बाधित करती रहती हैं जब वे फिट होना बंद कर चुकी होती हैं। कुछ संकेतों का एक छोटा समूह चुनकर इसे ठोस बनाएं — कार्य का प्रवाह, निर्णय-का-समय, पुनः कार्य, और टीम स्वास्थ्य — और इस पर सहमत हों कि उनमें क्या गति एक सोच-समझकर किए गए पुनर्डिज़ाइन बनाम एक छोटे समायोजन को ट्रिगर करेगी। एक ईमानदार उत्तर कुछ अग्रणी संकेतकों के लिए प्रतिबद्ध होता है, साक्ष्य-नेतृत्व वाले परिवर्तन को पुनर्गठन थिएटर से अलग करता है, और यह स्पष्ट है कि मॉडल का निरीक्षण करने और जब संकेत कहें कि यह डिलीवरी में बाधा डाल रहा है तो कार्य करने के लिए कौन जवाबदेह है।

व्यवहार में: एक स्वास्थ्य और देखभाल उदाहरण#

पांच स्थानों को कवर करने वाली एक ICS में हर ट्रस्ट अपने स्वयं के रोगी-सामना करने वाले अपॉइंटमेंट टूल बना रहा है। लागत दोहराती है, अनुभव अलग होते हैं, और कोई भी डेटा को साफ़ तरीके से साझा नहीं करता। ICS अपने संचालन मॉडल को फिर से डिज़ाइन करता है।

यह तीन परिणाम परिभाषित करता है (नहीं-आना कम करें, टालने योग्य प्रवेश कम करें, अभिगम समानता में सुधार करें) और उनके पीछे की मूल्य धाराएं। यह चार सबसे-पतली-व्यावहार्य क्षमताओं के स्वामित्व वाली एक छोटी प्लेटफ़ॉर्म टीम खड़ी करता है: एक साझा पहचान/लॉगिन, एक FHIR-आधारित अंतरसंचालनीयता परत, सुरक्षा और क्लिनिकल-सुरक्षा आधार रेखाओं के साथ सामान्य होस्टिंग, और एक डिज़ाइन सिस्टम। हर स्थान एक स्ट्रीम-संरेखित टीम रखता है लेकिन अब शुरू से बनाने के बजाय प्लेटफ़ॉर्म पर निर्माण करता है।

वित्तपोषण वार्षिक परियोजना बोलियों से हर स्ट्रीम के लिए स्थायी उत्पाद बजट में स्थानांतरित होता है, जो डिस्कवरी/अल्फा/बीटा द्वारों के माध्यम से जारी किया जाता है। एक प्रकाशित RAPID मानचित्र स्पष्ट करता है कि स्थान टीमें प्लेटफ़ॉर्म और क्लिनिकल-सुरक्षा गार्डरेल के भीतर अपनी स्वयं की सेवा डिज़ाइन तय करती हैं, जबकि ICS डिजिटल बोर्ड प्लेटफ़ॉर्म मानक तय करता है। एक वर्ष के भीतर, तीन स्थान एक बुकिंग क्षमता साझा करते हैं, डिज़ाइन और सुरक्षा आधार रेखा सुसंगत है, और नई सुविधाएं जो कभी एक परियोजना चक्र लेती थीं अब हफ्तों में शिप होती हैं — क्योंकि प्लेटफ़ॉर्म ने अविभेदित भारी काम को अवशोषित कर लिया।

क्षेत्र दृष्टिकोण#

एक संचालन मॉडल उस संगठन के अनुसार आकार दिया जाता है जिसकी वह सेवा करता है; वही परतें — मूल्य धाराएं, क्षमताएं, टीमें, प्रशासन, प्लेटफ़ॉर्म, आपूर्तिकर्ता — एक स्टार्टअप, एक उद्यम, और एक सरकारी निकाय द्वारा बहुत अलग तरीके से खींची जाती हैं।

स्टार्टअप#

एक छोटी डिजिटल-स्वास्थ्य कंपनी में संचालन मॉडल ज़्यादातर अंतर्निहित होता है और यह ठीक है: एक या दो स्ट्रीम-संरेखित टीमें, एक संस्थापक जो अधिकांश निर्णय अधिकार रखता है, और कोई प्लेटफ़ॉर्म टीम नहीं क्योंकि अभी प्लेटफ़ॉर्म बनाने के लिए कुछ नहीं है। अनुशासन कुछ वास्तविक निर्णयों को जल्दी स्पष्ट बनाना है — क्लिनिकल डेटा स्टोर के लिए बनाएं बनाम खरीदें, कौन से खुले मानकों के प्रति प्रतिबद्ध हों — ताकि आज का शॉर्टकट कल का लॉक-इन न बने। संचालन और परिवर्तन एक ही हाथों में बैठते हैं, इसलिए जोखिम यह है कि शुरुआती ग्राहकों के लिए लाइट जलाए रखना रोडमैप को भूखा रखता है; इंजीनियरिंग समय का एक सरल, ईमानदार विभाजन एक सुरक्षित संचालन बजट का हल्का समतुल्य है। आपूर्तिकर्ताओं को गति के लिए चुना जाता है, लेकिन एक स्टार्टअप को फिर भी मुख्य-क्लिनिकल-डेटा लॉक-इन से इनकार करना चाहिए, क्योंकि उसके भविष्य के NHS खरीदार निकास अधिकारों की मांग करेंगे।

छोटा व्यवसाय#

एक स्थापित छोटा प्रदाता — एक GP प्रैक्टिस, एक सामुदायिक फार्मेसी, एक केयर होम या घरेलू-देखभाल प्रदाता, एक एकल-साइट क्लिनिक, या पूर्व-राजस्व चरण से आगे एक छोटा स्वास्थ्य-तकनीक आपूर्तिकर्ता — के पास वास्तविक रोगी और चल रहे संचालन हैं लेकिन कोई प्लेटफ़ॉर्म टीम नहीं, कोई समर्पित डिजिटल या IT क्षमता नहीं, और नकदी या स्टाफ में बहुत कम ढील है। यहां संचालन मॉडल काफी हद तक एक साथ सिली गई खरीदी हुई क्षमताओं का एक समूह है, इसलिए निर्णायक विकल्प आपूर्तिकर्ता वाले हैं: आप जो क्लिनिकल सिस्टम खरीदते हैं उसमें खुले मानकों और निकास अधिकारों पर ज़ोर देना, क्योंकि आप एक बड़े ट्रस्ट के समान अंतरसंचालनीयता और क्लिनिकल-सुरक्षा कर्तव्य उठाते हैं बिना उसकी खरीद शक्ति या आंतरिक विशेषज्ञता के। संचालन और परिवर्तन उन्हीं मुट्ठी भर लोगों पर ढह जाते हैं जो देखभाल भी देते हैं, इसलिए ईमानदार अनुशासन केवल आग बुझाने के बजाय सिस्टम को सुरक्षित और अपडेट रखने के लिए थोड़ा समय सुरक्षित करना है। निर्णय अधिकार सरल हैं — आमतौर पर एक भागीदार या मालिक-प्रबंधक तय करता है — लेकिन इससे डिजिटल निर्णयों को अनिश्चित काल तक टालना आसान हो जाता है, इसलिए मूल्य कुछ महत्वपूर्ण निर्णयों को नाम देने में है (कौन सा क्लिनिकल रिकॉर्ड, किस साझा क्षेत्रीय प्लेटफ़ॉर्म में शामिल हों) और उन्हें सोच-समझकर बनाने में है। जहां एक ICS या राष्ट्रीय निकाय एक साझा पहचान, अंतरसंचालनीयता, या डिज़ाइन प्लेटफ़ॉर्म प्रदान करता है, वहां छोटे व्यवसाय की सबसे अच्छी चाल अक्सर उसका पुनः आविष्कार करने के बजाय उस पर निर्माण करना है, उस क्षमता को उधार लेना जिसे वह स्वयं स्टाफ नहीं कर सकता।

बड़ा संगठन#

एक NHS ट्रस्ट या ICS वह जगह है जहां प्लेटफ़ॉर्म-प्लस-संघवाद आकार अपना मूल्य अर्जित करता है: संप्रभु संगठन जिन्हें एक रोगी के लिए एक सेवा जैसा महसूस होना चाहिए। कठिन समस्याएं उतनी ही राजनीतिक हैं जितनी तकनीकी — पैसे को समय-सीमित परियोजना बोलियों से स्थायी उत्पाद बजट में ले जाना, और एक RACI/RAPID मानचित्र प्रकाशित करना ताकि स्थान टीमें उन निर्णयों को आगे बढ़ाना बंद करें जिनका वे स्वामित्व रखती हैं। एक बड़े स्वास्थ्य-तकनीक या फार्मा उद्यम के पास प्लेटफ़ॉर्म इंजीनियरिंग की ताकत है लेकिन एक भव्य आंतरिक प्लेटफ़ॉर्म को अत्यधिक-निर्माण करने का जोखिम है जो अपनी खुद की अड़चन बन जाता है; सबसे-पतला-व्यावहार्य-प्लेटफ़ॉर्म परीक्षण — दो या अधिक टीमों को प्रमाणित रूप से एक ही चीज़ की आवश्यकता है — ही रोक है। इस पैमाने पर, निर्णय अधिकार और वित्तपोषण प्रवाह ही संचालन मॉडल हैं; प्रौद्योगिकी आमतौर पर बाधा नहीं है।

सरकार#

एक राष्ट्रीय या स्थानीय सार्वजनिक निकाय ऐसे संचालन मॉडल डिज़ाइन करता है जिनमें अन्य संगठनों को रहना होता है, इसलिए मानकों और प्लेटफ़ॉर्म के बारे में उसके विकल्प प्रभावी रूप से राष्ट्रीय बुनियादी ढांचा हैं। NHS England या DHSC एक साझा पहचान परत, एक अंतरसंचालनीयता स्पाइन, या एक डिज़ाइन सिस्टम प्रदान करना जनसंख्या पैमाने पर लागू किया गया प्लेटफ़ॉर्म पैटर्न है, और उसके व्यय नियंत्रण और चरणबद्ध आश्वासन द्वार यह हैं कि सार्वजनिक धन को कैसे जवाबदेह रखा जाता है। विफलता विधा एक केंद्रीकृत मॉडल है जो एक दूरस्थ अड़चन बन जाता है, हर स्थानीय संदर्भ के लिए एक समाधान अनिवार्य करता है; सुधार वास्तव में सामान्य क्षमताओं को प्लेटफ़ॉर्म करना और बाकी को ट्रस्ट और स्थानीय अधिकारियों को सौंपना है। संसद के प्रति जवाबदेही का अर्थ यह भी है कि बनाएं/खरीदें और आपूर्तिकर्ता प्रबंधन सार्वजनिक रिकॉर्ड के मामले हैं, इसलिए खुले मानक और निकास अधिकार केवल विवेकपूर्ण नहीं बल्कि अपेक्षित हैं।

सामान्य विफलता मोड#

• संगठन चार्ट को स्वचालित करना। मूल्य धाराओं के बजाय मौजूदा विभागों के आसपास टीमों को डिज़ाइन करना, जिससे TOM साइलो को गहरा करता है। उपाय: परिणामों और मूल्य धाराओं से नीचे की ओर डिज़ाइन करें।
• एक अड़चन बनने वाला प्लेटफ़ॉर्म। एक अत्यधिक-दायरे वाली केंद्रीय प्लेटफ़ॉर्म टीम जिसके पीछे हर अनुरोध को कतार में लगना चाहिए। उपाय: सबसे पतला व्यावहार्य प्लेटफ़ॉर्म, SLA वाले उत्पाद के रूप में माना गया।
• उत्पाद कार्य के लिए परियोजना वित्तपोषण। पैसा जो समाप्त हो जाता है, भंग-और-पुनर्निर्माण उथल-पुथल मजबूर करता है। उपाय: चरणबद्ध द्वारों के साथ स्थायी उत्पाद वित्तपोषण।
• परिवर्तन को खिलाने के लिए भूखा किया गया संचालन। लाइव-सेवा संचालन को तब तक कम-वित्तपोषित करना जब तक क्लिनिकल सिस्टम खराब न हो जाएं। उपाय: संचालन और परिवर्तन को स्पष्ट रूप से वित्तपोषित करें और संचालन बजट की रक्षा करें।
• अस्वामित्व वाले निर्णय। किसी को नहीं पता कि कौन तय करता है, इसलिए सब कुछ आगे बढ़ता है। उपाय: एक प्रकाशित RACI/RAPID।
• डिफ़ॉल्ट रूप से लॉक-इन। बिना किसी निकास के एक मालिकाना आपूर्तिकर्ता सिस्टम में फंसा मुख्य क्लिनिकल डेटा। उपाय: हर रणनीतिक अनुबंध में खुले मानक और निकास अधिकार।

परिपक्वता मॉडल#

जांच-सूची#

• संचालन मॉडल परिणामों और मूल्य धाराओं से डिज़ाइन किया गया है, मौजूदा पदानुक्रम से नहीं।
• साझा क्षमताएं एक सबसे-पतले-व्यावहार्य प्लेटफ़ॉर्म के रूप में प्रदान की जाती हैं, जिसके ऊपर स्ट्रीम टीमें निर्माण करती हैं।
• उत्पाद टीमों को लगातार वित्तपोषित किया जाता है और मूल्य धाराओं के साथ संरेखित किया जाता है।
• व्यय नियंत्रण चरणबद्ध है (डिस्कवरी/अल्फा/बीटा/लाइव द्वार) और जोखिम और मूल्य के अनुपात में है।
• निर्णय अधिकार दस्तावेज़ीकृत (RACI या RAPID) और प्रकाशित हैं।
• संचालन और परिवर्तन को स्पष्ट रूप से वित्तपोषित किया जाता है, संचालन बजट की रक्षा के साथ।
• टीम प्रकार (स्ट्रीम-संरेखित, प्लेटफ़ॉर्म, सक्षम बनाना, जटिल-उपप्रणाली) समझे और उपयोग किए जाते हैं।
• बनाएं/खरीदें प्रति क्षमता एक सोच-समझकर लिया गया विकल्प है; मुख्य क्लिनिकल डेटा लॉक-इन से बचता है।
• अनुबंधों में खुले मानक (जैसे HL7 FHIR, SNOMED CT) और निकास अधिकार आवश्यक हैं।

मुख्य स्रोत#

• Matthew Skelton & Manuel Pais — Team Topologies (स्ट्रीम-संरेखित, प्लेटफ़ॉर्म, सक्षम बनाना, जटिल-उपप्रणाली टीमें; सबसे पतला व्यावहार्य प्लेटफ़ॉर्म)।
• GOV.UK Service Manual — व्यय नियंत्रण और चरणबद्ध आश्वासन (डिस्कवरी/अल्फा/बीटा/लाइव); Government Digital Service।
• NHS digital service manual — NHS service standard (service-manual.nhs.uk)।
• AXELOS — पोर्टफोलियो और प्रोग्राम प्रशासन के लिए Management of Portfolios (MoP) और Managing Successful Programmes (MSP)।
• Bain & Company — RAPID निर्णय-अधिकार ढांचा; और RACI जवाबदेही-असाइनमेंट मॉडल।
• John Doerr — परिणाम परिभाषा के लिए 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