विषय 4.1 — प्लेटफ़ॉर्म और साझा सेवाएं

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

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

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

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

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

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

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

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

तकनीकी रूप से, प्लेटफ़ॉर्म अक्सर अपनी क्षमताओं को एक application programming interface (API) के माध्यम से उजागर करते हैं — एक परिभाषित अनुबंध जो एक सिस्टम को दूसरे की क्षमता का उपयोग करने देता है बिना इसके आंतरिक भागों को जाने। वे अक्सर क्लाउड platform as a service (PaaS) मॉडलों पर आधारित होते हैं, और साझा राष्ट्रीय प्लेटफ़ॉर्म आमतौर पर मल्टीटेनेंसी पर निर्भर करते हैं, जहां एक एकल इंस्टेंस कई संगठनों की सेवा करता है जबकि उनका डेटा और कॉन्फ़िगरेशन अलग रखता है।

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

विशेष रूप से स्वास्थ्य में, राष्ट्रीय साझा सेवाएं पहले से परिदृश्य का हिस्सा हैं। NHS Connecting for Health जैसे ऐतिहासिक कार्यक्रमों ने NHS Spine स्थापित किया, राष्ट्रीय सेवाओं का एक समूह जो Personal Demographics Service जैसे मुख्य डेटा ले जाता है। आधुनिक समकक्षों में राष्ट्रीय API, नागरिक प्रमाणीकरण के लिए NHS login, और संदेश के लिए NHS Notify शामिल हैं — ऐसी क्षमताएं पेश की गईं ताकि व्यक्तिगत सेवाओं को उन्हें फिर से बनाने की आवश्यकता न हो। जहां एक प्लेटफ़ॉर्म यह साबित करने का एक सामान्य तरीका प्रदान करता है कि कोई कौन है, यह अक्सर single sign-on उजागर करता है ताकि एक क्लिनिशियन बार-बार के बजाय एक बार प्रमाणित हो। यह विषय ऐसे प्लेटफ़ॉर्म को कैसे बनाया और चलाया जाए इससे संबंधित है; आप कौन हैं और आप क्या कर सकते हैं इसके विवरण विषय 4.2 — पहचान और अभिगम प्रबंधन से संबंधित हैं, और सिस्टमों को डेटा का आदान-प्रदान करने देने वाले मानक विषय 4.3 — अंतरसंचालनीयता और डेटा मानक से संबंधित हैं।

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

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

2. सबसे पतले व्यावहार्य प्लेटफ़ॉर्म से शुरू करें। साझा क्षमताओं का सबसे छोटा समूह बनाएं जो वास्तव में टीमों को राहत देता है, और केवल तभी और जोड़ें जब वास्तविक मांग और वास्तविक पीड़ा इसे उचित ठहराए। यह "सबसे पतला व्यावहार्य प्लेटफ़ॉर्म" विचार, विषय 1.1 — संचालन मॉडल में पेश किया गया, सबसे सामान्य विफलता के विरुद्ध रक्षा करता है: एक महत्वाकांक्षी केंद्रीय प्लेटफ़ॉर्म जो सब कुछ करने की कोशिश करता है, देर से पहुंचता है, और किसी के लिए फिट नहीं होता। प्लेटफ़ॉर्म को उपयोग के साक्ष्य से बढ़ने दें, आर्किटेक्चरल आकांक्षा से नहीं।

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

4. अस्तित्व से नहीं, अपनाने और उपयोगकर्ता अनुभव से सफलता मापें। सही मीट्रिक यह हैं कि कितनी टीमें स्वेच्छा से प्लेटफ़ॉर्म का उपयोग करती हैं, ऑनबोर्डिंग में कितना समय लगता है, प्लेटफ़ॉर्म कितनी बार उपलब्ध है, और इसके उपयोगकर्ता अनुभव को कैसे रेट करते हैं। तैनात सेवाओं की संख्या जैसे वैनिटी मीट्रिक आपको कुछ नहीं बताते कि क्या टीमों की मदद हो रही है। प्लेटफ़ॉर्म को इंस्ट्रूमेंट करें, इस पर बनने वाली टीमों के साथ नियमित अनुसंधान चलाएं, और एक गिरते या ठहरे हुए अपनाने वाले वक्र को एक अनुपालन समस्या के बजाय एक उत्पाद समस्या मानें जिसे ठीक करना है।

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

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

7. स्पष्ट ज़िम्मेदारियों और सीमाओं के साथ प्लेटफ़ॉर्म टीम चलाएं। एक समर्पित प्लेटफ़ॉर्म टीम के आसपास व्यवस्थित करें जिसका काम स्व-सेवा के माध्यम से स्ट्रीम-संरेखित डिलीवरी टीमों को सक्षम बनाना है, जैसा विषय 7.0 — टीम संरचनाएं, भूमिकाएं और ज़िम्मेदारियां में Team Topologies पैटर्न में वर्णित है। प्लेटफ़ॉर्म और उपभोक्ताओं के बीच इंटरफ़ेस को स्पष्ट रखें — प्लेटफ़ॉर्म क्या वादा करता है, क्या नहीं करता, और समर्थन कैसे प्राप्त करें — ताकि प्लेटफ़ॉर्म गेटकीप करने के बजाय सक्षम बनाए।

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

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

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

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

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

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

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

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

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

कई NHS ट्रस्ट, सामुदायिक प्रदाता, और एक काउंटी काउंसिल की वयस्क सामाजिक देखभाल सेवा को कवर करने वाला एक Integrated Care System (ICS) बार-बार उसी दीवार से टकराता है। हर नई डिजिटल सेवा — एक वर्चुअल वार्ड, सामुदायिक फिजियोथेरेपी के लिए एक स्व-रेफरल फ़ॉर्म, एक केयर-होम निगरानी उपकरण — अपने पहले तीन महीने उन्हीं नींवों को फिर से बनाने में बिताती है: यह साबित करना कि रोगी कौन है, पेशेवर की भूमिका जांचना, SMS अनुस्मारक भेजना, और एक ऑडिट ट्रेल लिखना। वर्चुअल-वार्ड टीम का रोगी-मिलान फिजियोथेरेपी टीम से कमज़ोर साबित होता है, और एक निकट-चूक होती है जब एक अनुस्मारक गलत व्यक्ति को भेजा जाता है। ICS का डिजिटल नेतृत्व पैटर्न पहचानता है: वे उन क्षमताओं के लिए कई गुना भुगतान कर रहे हैं जो एक बार मौजूद होनी चाहिए, और भिन्नता एक सुरक्षा जोखिम है।

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

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

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

स्टार्टअप#

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

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

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

बड़ा संगठन#

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

सरकार#

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

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

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

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

जांच-सूची#

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

मुख्य स्रोत#

• GOV.UK Service Manual और प्लेटफ़ॉर्म के रूप में सरकार और सामान्य घटकों पर Government Digital Service लेखन।
• Matthew Skelton और Manuel Pais, Team Topologies — प्लेटफ़ॉर्म टीमें, सबसे पतला व्यावहार्य प्लेटफ़ॉर्म, और संज्ञानात्मक भार।
• NHS England डेवलपर और API मार्गदर्शन (NHS login, NHS Notify, राष्ट्रीय API, और Spine सेवाएं)।
• स्वास्थ्य IT सिस्टमों के लिए DCB0129 और DCB0160 क्लिनिकल जोखिम प्रबंधन मानक।
• डिजिटल सार्वजनिक बुनियादी ढांचे और पुनः उपयोग करने योग्य सार्वजनिक निर्माण खंडों पर World Bank और United Nations लेखन।
• Tim O'Reilly, "Government as a Platform", in Open Government (O'Reilly Media)।

संदर्भ#

1. Digital public infrastructure — Wikipedia — https://en.wikipedia.org/wiki/Digital_public_infrastructure
2. Shared services — Wikipedia — https://en.wikipedia.org/wiki/Shared_services
3. API (application programming interface) — Wikipedia — https://en.wikipedia.org/wiki/API
4. Platform as a service — Wikipedia — https://en.wikipedia.org/wiki/Platform_as_a_service
5. Multitenancy — Wikipedia — https://en.wikipedia.org/wiki/Multitenancy
6. Cognitive load — Wikipedia — https://en.wikipedia.org/wiki/Cognitive_load
7. Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
8. Open standard — Wikipedia — https://en.wikipedia.org/wiki/Open_standard
9. NHS Connecting for Health (including the NHS Spine and Personal Demographics Service) — Wikipedia — https://en.wikipedia.org/wiki/NHS_Connecting_for_Health
10. Single sign-on — Wikipedia — https://en.wikipedia.org/wiki/Single_sign-on
11. Team Topologies: Organizing Business and Technology Teams for Fast Flow — Matthew Skelton and Manuel Pais (IT Revolution Press) — https://teamtopologies.com/book
12. Government as a Platform — Tim O'Reilly, in Open Government (O'Reilly Media) — https://www.oreilly.com/library/view/open-government/9781449381936/ch02.html
13. GOV.UK Service Manual — Government Digital Service — https://www.gov.uk/service-manual
14. NHS login and NHS England developer/API guidance — NHS England — https://digital.nhs.uk/services/nhs-login
15. Clinical risk management: its application in the manufacture of health IT systems (DCB0129) — NHS England — https://digital.nhs.uk/services/clinical-safety/documentation