विषय 1.0 — डिजिटल स्वास्थ्य और देखभाल में काम करने के तरीके

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

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

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

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

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

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

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

उपयोगकर्ता-केंद्रित डिज़ाइन का अर्थ है एक मान ली गई समाधान से नहीं, बल्कि सेवा का उपयोग करने वाले लोगों — रोगियों, देखभालकर्ताओं, क्लिनिशियनों, प्रशासकों — की आवश्यकताओं से शुरुआत करना। यूके की Government Digital Service (GDS) और NHS ने इसे सेवा मानकों में संहिताबद्ध किया: निर्माण से पहले उपयोगकर्ताओं और उनकी आवश्यकताओं को समझें, और पूरे समय वास्तविक उपयोगकर्ताओं के साथ परीक्षण करते रहें।

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

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

परियोजना से बढ़कर उत्पाद। एक परियोजना की एक शुरुआत, एक अंत, और एक हस्तांतरण होता है; एक उत्पाद को उसके पूरे जीवन के लिए वित्तपोषित और संरक्षित किया जाता है। परियोजना से उत्पाद सोच की ओर बदलाव (देखें विषय 1.1 और विषय 5.0 — उत्पाद-नेतृत्व वाला कार्य) वित्तपोषण, टीमों, और जवाबदेही को बदलता है, और यह स्वास्थ्य सेवाओं के लिए — जो दीर्घजीवी और निरंतर विकसित होती हैं — एक बार की परियोजनाओं की तुलना में कहीं बेहतर फिट बैठता है।

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

1. अनुसंधान द्वारा प्रमाणित उपयोगकर्ता आवश्यकताओं से शुरू करें। निर्माण के लिए प्रतिबद्ध होने से पहले, यह समझें कि उपयोगकर्ता कौन हैं, वे क्या करने का प्रयास कर रहे हैं, और वर्तमान सेवा उन्हें कहां निराश करती है। एक डिस्कवरी को वित्तपोषित करें (देखें विषय 3.4 — डिस्कवरी चरण) और "हमने मान लिया" को एक चेतावनी संकेत मानें। हर बाद के निर्णय के लिए उपयोगकर्ता की आवश्यकताएं, न कि आंतरिक प्राथमिकताएं, आधार हैं।

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

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

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

5. साक्ष्य के साथ निर्णय लें, और निर्णय को दर्ज करें। क्लिनिकल साक्ष्य (क्या यह काम करता है और सुरक्षित है?) को डिलीवरी साक्ष्य (क्या हम इसे अच्छी तरह बना रहे हैं और इसका उपयोग हो रहा है?) से अलग करें, और एक हल्का निर्णय लॉग रखें ताकि कारण कर्मचारी बदलाव के बावजूद बने रहें (देखें विषय 1.3 — साक्ष्य-आधारित निर्णय)। साक्ष्य सबसे अधिक वेतन पाने वाले व्यक्ति की राय को हराता है।

6. अंतरसंचालनीयता और पुनः उपयोग के लिए डिज़ाइन करें। स्वास्थ्य और देखभाल डेटा को संगठनों के बीच सुरक्षित रूप से प्रवाहित होना चाहिए; खुले मानकों (HL7 FHIR, SNOMED CT) पर निर्माण करें और प्लेटफ़ॉर्म को फिर से बनाने के बजाय पुनः उपयोग करें (देखें विषय 1.1 का "सबसे पतला व्यावहार्य प्लेटफ़ॉर्म" और विषय 4.3 — अंतरसंचालनीयता और डेटा मानक)। एक सेवा जो डेटा साझा नहीं कर सकती वह एक साइलो है जो जोखिम बनने की प्रतीक्षा कर रहा है।

7. आनुपातिक रूप से प्रशासन करें। आश्वासन के वज़न को जोखिम के स्तर से मिलाएं। उच्च-जोखिम वाले क्लिनिकल परिवर्तन गहन जांच के योग्य हैं; कम-जोखिम वाले सामग्री परिवर्तनों को एक बोर्ड के लिए हफ्तों प्रतीक्षा नहीं करनी चाहिए। आनुपातिक प्रशासन आपको सुरक्षित और तेज़ दोनों रखता है।

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

9. दीर्घकाल और हस्तांतरण के लिए डिज़ाइन करें। स्वास्थ्य में डिजिटल सेवाएं उन टीमों और अनुबंधों से अधिक जीवित रहती हैं जो उन्हें बनाते हैं, इसलिए निर्णयों को दर्ज करें, अदस्तावेज़ीकृत "हीरो" ज्ञान से बचें, और उन लोगों के लिए डिज़ाइन करें जो वर्षों तक सेवा को चलाएंगे और बदलेंगे (देखें विषय 10.3 — ज्ञान प्रबंधन और दस्तावेज़ीकरण)। स्थिरता — टीम की, प्रौद्योगिकी की और वित्तपोषण मॉडल की — को एक प्रथम-श्रेणी बाधा के रूप में मानें, न कि बाद का विचार।

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

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

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

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

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

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

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

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

एक एकीकृत देखभाल प्रणाली तीन एक्यूट ट्रस्ट, सामुदायिक सेवाओं, और स्थानीय प्राधिकरण सामाजिक देखभाल में क्लिनिशियनों को एक साझा देखभाल रिकॉर्ड देना चाहती है। पुराना तरीका एक निश्चित-दायरे वाला प्रोग्राम कमीशन करता, हर स्क्रीन को पहले से निर्दिष्ट करता, और देर से एकीकृत करता।

इसके बजाय ICS एक बहु-विषयक टीम बनाता है: एक उत्पाद प्रबंधक, डिलीवरी प्रबंधक, उपयोगकर्ता शोधकर्ता, इंटरैक्शन डिज़ाइनर, दो इंजीनियर, एक क्लिनिकल सुरक्षा अधिकारी, और एक सूचना प्रशासन प्रमुख, एक caldicott गार्डियन और एक सामाजिक-देखभाल व्यवसायी तक अभिगम के साथ। वे एक आठ-सप्ताह की डिस्कवरी चलाते हैं, यह देखते हुए कि एक ज़िला नर्स, एक A&E कंसल्टेंट, और एक सामाजिक कार्यकर्ता आज वास्तव में जानकारी कैसे खोजने की कोशिश करते हैं। वे पाते हैं कि वास्तविक पीड़ा "कोई डेटा नहीं" नहीं बल्कि "ऐसा डेटा जिसकी वर्तमानता पर वे भरोसा नहीं कर सकते" है।

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

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

वही चार दबाव — सुरक्षा, समानता, कर्तव्य, धन — हर संगठन पर असर डालते हैं, लेकिन जो काम करने के तरीके उनका जवाब देते हैं वे पैमाने, वित्तपोषण, और जवाबदेही के साथ बदलते हैं।

स्टार्टअप#

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

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

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

बड़ा संगठन#

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

सरकार#

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

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

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

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

जांच-सूची#

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

मुख्य स्रोत#

• NHS डिजिटल सेवा मैनुअल — NHS सेवा मानक और इसके बिंदु, जिसमें "एजाइल काम करने के तरीकों का उपयोग करें" और "एक ऐसी टीम बनाएं जिसमें बहु-विषयक कौशल और दृष्टिकोण शामिल हों" शामिल है (service-manual.nhs.uk)।
• GOV.UK Service Manual और Government Service Standard — Government Digital Service (gov.uk/service-manual)।
• NHS England / NHSX — डिजिटल प्रौद्योगिकी मूल्यांकन मानदंड (DTAC)।
• क्लिनिकल सुरक्षा मानक DCB0129 और DCB0160 (NHS England / पूर्व NHS Digital)।
• NICE — डिजिटल स्वास्थ्य प्रौद्योगिकियों के लिए Evidence Standards Framework (nice.org.uk)।
• NHS England — स्वास्थ्य असमानताओं को कम करने के लिए Core20PLUS5 दृष्टिकोण।

संदर्भ#

1. User-centered design — Wikipedia — https://en.wikipedia.org/wiki/User-centered_design
2. Government Digital Service — Wikipedia — https://en.wikipedia.org/wiki/Government_Digital_Service
3. Agile software development — Wikipedia — https://en.wikipedia.org/wiki/Agile_software_development
4. Iterative and incremental development — Wikipedia — https://en.wikipedia.org/wiki/Iterative_and_incremental_development
5. Interdisciplinarity — Wikipedia — https://en.wikipedia.org/wiki/Interdisciplinarity
6. Product management — Wikipedia — https://en.wikipedia.org/wiki/Product_management
7. Health equity — Wikipedia — https://en.wikipedia.org/wiki/Health_equity
8. Web Content Accessibility Guidelines — Wikipedia — https://en.wikipedia.org/wiki/Web_Content_Accessibility_Guidelines
9. Fast Healthcare Interoperability Resources (HL7 FHIR) — Wikipedia — https://en.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources
10. SNOMED CT — Wikipedia — https://en.wikipedia.org/wiki/SNOMED_CT
11. NHS service standard — NHS digital service manual, NHS England — https://service-manual.nhs.uk/standards-and-technology/service-standard
12. Government Service Standard — Government Digital Service, GOV.UK — https://www.gov.uk/service-manual/service-standard
13. Digital Technology Assessment Criteria (DTAC) — NHS England — https://www.nhs.uk/digital-technology-assessment-criteria-dtac/
14. Clinical Risk Management: DCB0129 and DCB0160 — NHS England — https://digital.nhs.uk/services/clinical-safety
15. Evidence Standards Framework for digital health technologies — NICE — https://www.nice.org.uk/about/what-we-do/digital-health
16. Core20PLUS5 — NHS England — https://www.england.nhs.uk/about/equality/equality-hub/national-healthcare-inequalities-improvement-programme/core20plus5/