सॉफ़्टवेयर इंजीनियरिंग स्वास्थ्य अर्थशास्त्र

स्वास्थ्य अर्थशास्त्र में यह क्यों महत्वपूर्ण है

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

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

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

मूल अवधारणाएँ

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

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

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

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

पाँचवाँ, अंतरसंचालनीयता: प्रणालियों की जानकारी का आदान-प्रदान करने और जो आदान-प्रदान किया जाता है उसका उपयोग करने की क्षमता। इसका अर्थशास्त्र नेटवर्क प्रभाव का अर्थशास्त्र है — हर प्रणाली जो एक सामान्य मानक बोलती है वह हर अन्य प्रणाली का मूल्य बढ़ाती है जो करती है — यही कारण है कि अंतरसंचालनीयता दीर्घकालिक रूप से बाज़ारों द्वारा कम-आपूर्ति की जाती है: लाभ पूरी प्रणाली को मिलते हैं जबकि लागतें हर विक्रेता और ख़रीदार पर पड़ती हैं, और एक मौजूदा खिलाड़ी अंतरसंचालन न करने से लाभ कमा सकता है। फ़ास्ट हेल्थकेयर इंटरऑपरेबिलिटी रिसोर्सेज़ (FHIR), HL7 परिवार जिससे यह संबंधित है, और openEHR जैसे मानक इन विनिमय लागतों को कम करने के लिए मौजूद हैं, और नियामक — उदाहरण के लिए संयुक्त राज्य अमेरिका 21वीं सदी क्योर्स एक्ट जानकारी-अवरोधन नियमों के माध्यम से, और यूरोपीय संघ यूरोपीय स्वास्थ्य डेटा स्पेस के माध्यम से — जो बाज़ार ने नहीं दिया उसे अनिवार्य करना शुरू कर दिया है।

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

छोटा व्यवसाय

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

उद्यम (एंटरप्राइज़)

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

सरकार

एक मंत्रालय या राष्ट्रीय भुगतानकर्ता बाक़ी सभी के लिए इस अर्थशास्त्र को आकार देता है। यह अंतरसंचालनीयता नियम निर्धारित करता है जो तय करते हैं कि क्या बाज़ार खुलेपन को पुरस्कृत या दंडित करता है — जैसे संयुक्त राज्य अमेरिका ने 21वीं सदी क्योर्स एक्ट के जानकारी-अवरोधन प्रावधानों और यूरोपीय संघ ने यूरोपीय स्वास्थ्य डेटा स्पेस के साथ किया — और इसकी अपनी ख़रीद विक्रेताओं को सिखाती है कि ख़रीदार क्या सहन करेंगे। इसका विशिष्ट विफलता तरीक़ा राष्ट्रीय मेगा-कार्यक्रम है: केंद्रीकृत, बड़ा-धमाका, राजनीतिक रूप से समयबद्ध सॉफ़्टवेयर वितरण जिसका पतन अरबों में मापा जाता है, जैसा यूके के नेशनल प्रोग्राम फ़ॉर 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