क्या एजाइल को हेल्थकेयर आईटी जैसे क्षेत्र में नियोजित किया जा सकता है, जहां रोगियों की इतनी देखभाल, प्रणालियों की गुणवत्ता और समय पर वितरण पर निर्भर करती है?
जवाबों:
हां, स्वास्थ्य विकास आईटी विकास में चुस्त विकास की भूमिका है। कोई नहीं, अंत-उपयोगकर्ता नहीं, रोगी नहीं और निश्चित रूप से विकास टीम अच्छी तरह से की गई विकास प्रक्रिया द्वारा अच्छी तरह से सेवा नहीं करती है। कुछ सिद्धांतों को ध्यान में रखते हुए जो कि एजाइल मेनिफेस्टो (विकीपीडिया से मेरी टिप्पणी के साथ बेशर्मी से फट गई सूची):
एफडीए विनियमित सेटिंग में एजाइल मेडिकल डिवाइस सॉफ्टवेयर डेवलपमेंट के उपयोग के बारे में चर्चा थोड़ी देर के लिए हुई है और इस प्रश्न के लिए प्रासंगिक है। यहाँ कुछ कारण है क्यूँ:
छोटा जवाब हां है"। एक लंबा लेकिन अधिक सटीक उत्तर है "यदि आप इसे गंभीरता से लेते हैं।"
ध्यान में रखने के लिए कुछ विषय हैं, जिन्हें मैं (ए) रोगी सुरक्षा और उत्पाद की गुणवत्ता, और (बी) उद्योग विनियमन से संबंधित चिंताओं में अलग करना पसंद करता हूं।
सुरक्षा और गुणवत्ता की ओर, ध्यान रखें कि सुरक्षित सॉफ़्टवेयर बनाना मुश्किल है। कुछ डोमेन ज्ञान के साथ कुछ अच्छे प्रोग्रामर अविश्वसनीय रूप से उपयोगी सॉफ़्टवेयर को क्रैंक कर सकते हैं जो बहुत सुरक्षित हैं। यदि वे एक स्थानीय नैदानिक सेटिंग में तैनाती का हिस्सा हैं, और सॉफ्टवेयर की तैनाती और उपयोग के दौरान घटनाओं का जवाब और समायोजन रख सकते हैं, तो सॉफ़्टवेयर केवल कुछ चोटों के साथ जीवन को मूल्य, बचत या सुधार प्रदान कर सकता है या त्रुटियों का उपयोग करने से संबंधित है। या सॉफ्टवेयर बग्स। लेकिन सॉफ़्टवेयर को प्रोग्रामर की आवश्यकता होगी, हर समय, सॉफ़्टवेयर के उपयोग के रूप में सॉफ़्टवेयर का उपयोग करते समय, प्रतिक्रिया करना, सह-विकसित करना। यह एक स्केलेबल प्रक्रिया नहीं है और जब प्रोग्रामर मर जाते हैं या ऊब जाते हैं तो सिस्टम आसानी से बहुत जल्दी खतरनाक हो सकता है। इन परिणामों को सुधारने और सुरक्षित सॉफ्टवेयर बनाने के लिए, सॉफ्टवेयर के विकसित होने के दौरान महत्वपूर्ण विकास प्रक्रिया के कदम उठाने होते हैं। मेडिकल डिवाइस सॉफ्टवेयर, आईएसओ / आईईसी 62304 के विकास के लिए एक अच्छा "आउट ऑफ द बॉक्स" अंतर्राष्ट्रीय मानक में पाया जा सकता है। मुख्य अवधारणा सभी चरणों में सुरक्षा जोखिम प्रबंधन है - उपयोग के मामले के विश्लेषण और कहानी के विकास के दौरान, आवश्यकताओं elucidation, प्रणाली और वास्तुशिल्प डिजाइन, कार्यान्वयन, इकाई और एकीकरण परीक्षण। फुर्तीली होने से इस काम में कोई कमी नहीं आएगी, या कम मुश्किल नहीं होगी, लेकिन मूल्य निर्माण पर ध्यान केंद्रित करके और काम को समाप्त करने से (जैसे कि अनावश्यक विशेषताएं, या अत्यधिक सत्यापन परीक्षण / फिक्स चक्र) जो मूल्य नहीं बनाता है, चुस्त विकास हो सकता है एक टीम को इस काम को विकास में एकीकृत करने की अनुमति दें, जिसके परिणामस्वरूप एक ही समय में सुरक्षित सॉफ़्टवेयर विकसित किया गया। आमतौर पर फुर्तीली टीमों द्वारा उपयोग किए जाने वाले पुनरावृत्ति विकास प्रथाओं को सुरक्षा जोखिम प्रबंधन कार्य करने के लिए बहुत अच्छी तरह से अनुकूल है, परियोजना के जीवन भर में विकसित होने के बजाय विकसित किया जाना चाहिए। और सॉफ्टवेयर के चालू होने के बाद, उपयोगकर्ताओं से प्रतिक्रिया और किसी भी घटना से संभावित रूप से चोट लगने की संभावना को व्यक्तिगत रूप से और समग्र रूप से माना जाता है, ताकि सॉफ्टवेयर का उपयोग करने के लिए सुरक्षित रखा जा सके। एजाइल यहां मदद कर सकता है यदि यह सिस्टम के अन्य हिस्सों को तोड़ने के बिना परिवर्तनों को शामिल करने के लिए एक फास्ट-ट्रैक, सुरक्षित प्रक्रिया प्रदान करता है - जो बदले में एक बार फिर एक अच्छी वास्तुकला और अच्छी तरह से समझे गए डिज़ाइन इंटरैक्शन की आवश्यकता होती है जो सॉफ़्टवेयर विकसित होने पर बनाए गए थे। परियोजना के जीवन भर विकसित होने के बजाय विकसित होना। और सॉफ्टवेयर के चालू होने के बाद, उपयोगकर्ताओं से प्रतिक्रिया और किसी भी घटना से संभावित रूप से चोट लगने की संभावना को व्यक्तिगत रूप से और समग्र रूप से माना जाता है, ताकि सॉफ्टवेयर का उपयोग करने के लिए सुरक्षित रखा जा सके। एजाइल यहां मदद कर सकता है यदि यह सिस्टम के अन्य हिस्सों को तोड़ने के बिना परिवर्तनों को शामिल करने के लिए एक फास्ट-ट्रैक, सुरक्षित प्रक्रिया प्रदान करता है - जो बदले में एक बार फिर एक अच्छी वास्तुकला और अच्छी तरह से समझे गए डिज़ाइन इंटरैक्शन की आवश्यकता होती है जो सॉफ़्टवेयर विकसित होने पर बनाए गए थे। परियोजना के जीवन भर विकसित होने के बजाय विकसित होना। और सॉफ्टवेयर के चालू होने के बाद, उपयोगकर्ताओं से प्रतिक्रिया और किसी भी घटना से संभावित रूप से चोट लगने की संभावना को व्यक्तिगत रूप से और समग्र रूप से माना जाता है, ताकि सॉफ्टवेयर का उपयोग करने के लिए सुरक्षित रखा जा सके। एजाइल यहां मदद कर सकता है यदि यह सिस्टम के अन्य हिस्सों को तोड़ने के बिना परिवर्तनों को शामिल करने के लिए एक फास्ट-ट्रैक, सुरक्षित प्रक्रिया प्रदान करता है - जो बदले में एक बार फिर एक अच्छी वास्तुकला और अच्छी तरह से समझे गए डिज़ाइन इंटरैक्शन की आवश्यकता होती है जो सॉफ़्टवेयर विकसित होने पर बनाए गए थे।
दूसरी चिंता नियामक है। एक आदर्श दुनिया में, सुरक्षा नियम उन सभी उत्पादों पर लागू होते हैं जो पर्याप्त रूप से खतरनाक हो सकते हैं, और एक विक्रेता लाइन को पार करने के लिए शुरू करने के बाद कुछ सरल चीजों का पालन करने में सक्षम होगा। व्यवहार में, वैश्विक नियम इस उद्योग में जटिल और तेजी से आगे बढ़ रहे हैं, जिसका अर्थ है कि एक दिन आप एक छोटा सा आईफोन ऐप विकसित कर सकते हैं जो कुछ चिकित्सा डेटा दिखाता है, और अगले आपको "गुणवत्ता प्रबंधन" के लिए आईएसओ और एफडीए मानकों का पालन करने की उम्मीद है सिस्टम ", या QMS। यह उन कंपनियों के लिए डरावना हो सकता है जिनके पास पूर्व में औपचारिक क्यूएमएस नहीं था। और फुर्तीली इसे बढ़ा सकती है क्योंकि आप एक उत्पाद अवधारणा के साथ शुरू कर सकते हैं, और विकासवादी विकास के माध्यम से अनजाने में एक विनियमित उद्देश्य के उपयोग में प्रवेश कर सकते हैं (जैसे कि उपयोगकर्ता को नैदानिक निदान डेटा प्रदर्शित करना)। अक्टूबर 2011 की बात है; किसी भी कंपनी को "स्वास्थ्य", "मेडिकल", "हेल्थकेयर" श्रेणी के नाम पर एक उत्पाद के विपणन पर विचार करने की मेरी सलाह यह है कि जब वे उत्पाद बनाते हैं, तो उनके पास एक या एक से अधिक चिकित्सा उपकरण नियामकों द्वारा दुनिया भर में विनियमित होने की योजना होनी चाहिए। यहां फिर से चुस्त मदद मिल सकती है, क्योंकि फुर्तीली प्रथाएं आमतौर पर प्री-मार्केट क्लीयरेंस सबमिशन (जैसे एफडीए 510k), प्रमाणन (जैसे आईएसओ 13485) और पोस्ट-मार्केट ऑपरेशंस के लिए विनियामक ग्राहकों को संतुष्ट करने के लिए आउटपुट का अनुपालन करती हैं। टेस्ट-प्रथम विकास चिकित्सा सॉफ्टवेयर में सही बैठता है। निरंतर एकीकरण, स्वचालित इकाई परीक्षण, और SCRUM स्प्रिंट मेटाडेटा पूर्ण उद्देश्य साक्ष्य प्रदान कर सकता है कि जोखिम प्रबंधन और उचित सत्यापन विकास प्रक्रिया में केवल एक विचार के रूप में नहीं बल्कि बेक किया गया है। ज्यादातर मामलों में मुझे लगता है कि फुर्तीले "झरना" की तुलना में अधिक कलाकृतियों का उत्पादन करते हैं, शायद उसी रूप में नहीं। लेकिन कुछ संतोषजनक नियामकों में आउटपुट का रूपांतरण हल करने के लिए एक अपेक्षाकृत छोटी समस्या है।
तो सारांश में ... हाँ वर्जीनिया, स्वास्थ्य देखभाल आईटी (और अन्य चिकित्सा उपकरण) सॉफ्टवेयर विकास के लिए चुस्त है। फुर्तीली सभी चीजों की तरह, यह प्रक्रिया, व्यापार समर्थन और साहस के लिए समर्पण लेता है।
हां, चुस्त विकास का एक स्थान ग्राहक की भागीदारी है। स्वास्थ्य सेवा आईटी प्रणालियों और प्रक्रियाओं में यह महत्वपूर्ण है। हेल्थकेयर आईटी विभाग बेहतर निर्णय लेंगे यदि ग्राहक प्रतिनिधि शामिल है और इनपुट दे रहा है कि कैसे फैसले रोगी की देखभाल को प्रभावित करेंगे।
मुझे लगता है कि यह संभव है, लेकिन उद्योग को एक बड़े प्रतिमान की जरूरत है। मैं हेल्थ केयर डेवलपर के रूप में अपने दूसरे वर्ष में हूं, और विश्वास और आत्म आयोजन कहीं भी स्पष्ट नहीं हैं। हेल्थकेयर को औपचारिक रूप से फुर्तीला अपनाने से बहुत फायदा होगा, क्योंकि यह ज्यादातर वैसे भी अराजकता है, "थ्रैश" नामक पुनरावृत्त विकास और देर से बदलती आवश्यकताओं के कारण, क्योंकि, बड़े डिजाइन अपफ्रंट वैसे भी काम नहीं करता है।
मैं आपका प्रश्न समझता हूँ। चंचल विकास का एक अच्छा उदाहरण किसी के लिए एक वेबसाइट का निर्माण कर रहा है। आमतौर पर एक ग्राहक को ठीक से पता नहीं होता कि वह क्या चाहता है, इसलिए ग्राहक के साथ बहुत अधिक बातचीत होती है।
हेल्थकेयर आईटी कंप्यूटर विज्ञान में बहुत पूर्वनिर्धारित क्षेत्र की तरह लग सकता है; सख्त मानकों (DICOM, HL7) के साथ ऐसा लगता है कि उन्हें लागू करने का केवल एक ही तरीका है, लेकिन बहुत सारी प्राथमिकताएँ और निर्णय लेना भी है।
मेरी राय में, जो भी उत्पाद आप बना रहे हैं, आप समय से पहले सभी आवश्यकताओं को निर्धारित करने में सक्षम नहीं हैं , इसलिए एक चुस्त सॉफ्टवेयर विकास विधि बहुत अच्छी तरह से काम करती है।
जैसा कि कहा गया है, इसका उत्तर हां है।
विनियमित या उच्च जोखिम वाले क्षेत्रों में एजाइल को लागू करते समय आपको प्रत्येक पुनरावृत्ति में "पूर्ण" को परिभाषित करना चाहिए, जैसे कि नियामक अनुपालन और अन्य जोखिम शमन रणनीतियों में शामिल हैं। उदाहरण के लिए, इसके लिए QA प्रलेखन, आवश्यकताएं पारगम्यता, सुरक्षा ऑडिट और अन्य कार्यों को हर पुनरावृत्ति पर पूरा करना पड़ सकता है।
उदाहरण के लिए, एफडीए विनियमित वातावरण के लिए चुस्त दृष्टिकोण के आवेदन के लिए अच्छी कला और अभ्यास है।
संक्षिप्त उत्तर: हाँ। हाई-एश्योरेंस वातावरण में एजाइल के बारे में एक अच्छा ब्लॉग है जो कुछ सुझाव देता है।
हालांकि, कुछ समझौते हैं जिन्हें बनाने की आवश्यकता है। चंचल घोषणा पर विचार करें :
व्यक्तियों और प्रक्रियाओं और उपकरणों पर बातचीत
व्यापक प्रलेखन पर काम कर रहे सॉफ्टवेयर
अनुबंध बातचीत पर ग्राहक सहयोग
एक योजना के बाद बदलने का जवाब
नियामक निकाय बायीं ओर उतना ही महत्व देते हैं, जितना कि फुर्तीली टीमें करती हैं, लेकिन उन्हें दाएं हाथ की ओर अधिक जोर देने की आवश्यकता होती है, जो एक विशिष्ट फुर्तीली टीम करती है। उदाहरण के लिए, FDA को यह आवश्यक है कि आप अपनी प्रक्रियाओं और औजारों को मान्य करते हैं, काफी व्यापक डिजाइन और परीक्षण प्रलेखन के लिए पूछते हैं, और निश्चित रूप से योजना के एक अच्छे सौदे की आवश्यकता होती है।
दूसरी ओर, कई चुस्त सिद्धांत स्वास्थ्य जगत में बहुत अच्छी तरह से फिट होते हैं, जिनमें शामिल हैं:
कुछ विषयों की प्रकृति पहले से ही चुस्त है। उदाहरण के लिए, नर्सिंग एक 'मूल्यांकन-मूल्यांकन-नियोजन-हस्तक्षेप-हस्तक्षेप' चक्र पर निर्भर करता है जो अंतिम परिणामों को प्राप्त करने के लिए निदान / रोग का निदान के कई पुनरावृत्तियों पर निर्भर करता है।
हालांकि, यह सुझाव देना घातक होगा कि इस तरह से प्रदान की जाने वाली स्वास्थ्य देखभाल सेवाएं विशेष रूप से उक्त सेवा वितरण में उपयोग के लिए एक सॉफ्टवेयर टूल या सिस्टम की ओर एजाइल सॉफ्टवेयर विकास के अनिवार्य रूप से एकल-आवृत्ति एप्लिकेशन के अनुकूल हैं।
AAMI सक्रिय रूप से एक तकनीकी सूचना रिपोर्ट हकदार पर काम कर रहा है:
AAMI TIR SW1, चिकित्सा उपकरण सॉफ्टवेयर के विकास में चुस्त प्रथाओं के उपयोग पर मार्गदर्शन।
मैंने सुना है कि यह 2012 में प्रकाशित हो सकता है।
यह नियामक आवश्यकताओं, विशिष्ट प्रक्रियाओं और चिकित्सा उपकरण सॉफ्टवेयर से जुड़े अन्य उत्पाद व्यावहारिकताओं के साथ एजाइल मेनिफेस्टो (एपिज्रेड्स उत्तर देखें) के सिद्धांतों के संरेखण पर चर्चा करता है।