สามารถใช้ Agile ในสาขาเช่น Healthcare IT ซึ่งการดูแลผู้ป่วยจำนวนมากขึ้นอยู่กับคุณภาพและการส่งมอบระบบที่ตรงเวลา?
คำตอบ:
ใช่การพัฒนาที่คล่องตัวมีบทบาทอย่างยิ่งในการพัฒนาระบบไอทีด้านการดูแลสุขภาพ ไม่มีใครไม่ใช่ผู้ใช้ไม่ใช่ผู้ป่วยและแน่นอนว่าทีมพัฒนาไม่ได้รับบริการอย่างดีจากกระบวนการพัฒนาที่ทำไม่ดี พิจารณาหลักการบางประการที่อยู่ภายใต้รายการ Agile (รายการที่ไม่ลงรอยกันจากวิกิพีเดียด้วยความเห็นของฉัน):
การอภิปรายเกี่ยวกับการใช้การพัฒนาซอฟต์แวร์อุปกรณ์การแพทย์ Agileในการตั้งค่าควบคุมของ FDA ได้เกิดขึ้นนานแล้วและเกี่ยวข้องกับคำถามนี้ นี่คือสาเหตุบางประการ:
คำตอบสั้น ๆ คือ "ใช่" คำตอบที่ยาว แต่แม่นยำกว่าคือ "ถ้าคุณจริงจังกับเรื่องนี้"
มีบางประเด็นที่ควรคำนึงถึงซึ่งฉันชอบแยกออกเป็นประเด็นที่เกี่ยวข้องกับ (a) ความปลอดภัยและคุณภาพของผลิตภัณฑ์ผู้ป่วยและ (b) ข้อบังคับอุตสาหกรรม
ในด้านความปลอดภัยและคุณภาพโปรดทราบว่าการสร้างซอฟต์แวร์ที่ปลอดภัยนั้นเป็นเรื่องยาก โปรแกรมเมอร์ที่ดีเพียงไม่กี่คนที่มีความรู้ด้านโดเมนบางรายอาจทำให้ซอฟต์แวร์ที่มีประโยชน์มีความปลอดภัยอย่างเหลือเชื่อ หากพวกเขาเป็นส่วนหนึ่งของการใช้งานในการตั้งค่าทางคลินิกในท้องถิ่นและสามารถตอบสนองและปรับตัวต่อเหตุการณ์ในระหว่างการใช้งานและการใช้งานซอฟต์แวร์ซอฟต์แวร์อาจให้คุณค่าการรักษาหรือปรับปรุงชีวิตด้วยการบาดเจ็บหรือเสียชีวิตเพียงไม่กี่ครั้ง หรือข้อบกพร่องของซอฟต์แวร์ แต่ซอฟต์แวร์จะต้องการให้โปรแกรมเมอร์อยู่ที่นั่นตลอดเวลาตอบสนองร่วมกันพัฒนาซอฟต์แวร์เมื่อมีการใช้ซอฟต์แวร์วิวัฒนาการ นี่ไม่ใช่กระบวนการที่ปรับขนาดได้และเมื่อโปรแกรมเมอร์ตายหรือเบื่อระบบอาจกลายเป็นอันตรายได้อย่างรวดเร็ว เพื่อปรับปรุงผลลัพธ์เหล่านี้และสร้างซอฟต์แวร์ที่ปลอดภัย มีขั้นตอนกระบวนการพัฒนาที่สำคัญที่ต้องดำเนินการในขณะที่มีการพัฒนาซอฟต์แวร์ การแนะนำ "ออกจากกล่อง" ที่ดีสามารถพบได้ในมาตรฐานสากลสำหรับการพัฒนาซอฟต์แวร์อุปกรณ์การแพทย์ ISO / IEC 62304 แนวคิดหลักคือการจัดการความเสี่ยงด้านความปลอดภัยในทุกขั้นตอน - ระหว่างการวิเคราะห์กรณีการใช้งานและการพัฒนาเรื่องราวความต้องการ การอธิบายระบบและการออกแบบสถาปัตยกรรมการใช้งานการทดสอบหน่วยและการรวม การมีความคล่องตัวจะไม่ทำให้งานชิ้นนี้หายไปหรือยากน้อยลง แต่โดยเน้นไปที่การสร้างคุณค่าและการกำจัดงาน (เช่นคุณสมบัติที่ไม่จำเป็นหรือการทดสอบการตรวจสอบ / รอบการแก้ไขที่มากเกินไป) ที่ไม่ได้สร้างคุณค่า อนุญาตให้ทีมรวมงานนี้เข้ากับการพัฒนาส่งผลให้ซอฟต์แวร์ที่ปลอดภัยยิ่งขึ้นได้รับการพัฒนาในเวลาเดียวกัน แนวทางการพัฒนาแบบวนซ้ำที่ใช้กันทั่วไปโดยทีมงานเปรียวนั้นเหมาะสมอย่างยิ่งกับการทำงานด้านการบริหารความเสี่ยงด้านความปลอดภัยซึ่งมีการพัฒนาไปตลอดชีวิตของโครงการแทนที่จะเป็นสิ่งที่ตามมาภายหลัง และหลังจากซอฟต์แวร์ทำงานได้ผลตอบรับจากผู้ใช้และเหตุการณ์ใด ๆ ที่อาจนำไปสู่การบาดเจ็บจำเป็นต้องได้รับการพิจารณาเป็นรายบุคคลและโดยรวมเพื่อให้ซอฟต์แวร์ปลอดภัยต่อการใช้งาน Agile สามารถช่วยได้ที่นี่หากมีกระบวนการที่รวดเร็วและปลอดภัยสำหรับการรวมการเปลี่ยนแปลงโดยไม่ทำลายส่วนอื่น ๆ ของระบบซึ่งจำเป็นต้องมีสถาปัตยกรรมที่ดีอีกครั้งและการโต้ตอบการออกแบบที่เข้าใจกันดีซึ่งสร้างขึ้นเมื่อซอฟต์แวร์ได้รับการพัฒนา การพัฒนาตลอดชีวิตของโครงการมากกว่าที่จะเป็นภายหลัง และหลังจากซอฟต์แวร์ทำงานได้ผลตอบรับจากผู้ใช้และเหตุการณ์ใด ๆ ที่อาจนำไปสู่การบาดเจ็บจำเป็นต้องได้รับการพิจารณาเป็นรายบุคคลและโดยรวมเพื่อให้ซอฟต์แวร์ปลอดภัยต่อการใช้งาน Agile สามารถช่วยได้ที่นี่หากมีกระบวนการที่รวดเร็วและปลอดภัยสำหรับการรวมการเปลี่ยนแปลงโดยไม่ทำลายส่วนอื่น ๆ ของระบบซึ่งจำเป็นต้องมีสถาปัตยกรรมที่ดีอีกครั้งและการโต้ตอบการออกแบบที่เข้าใจกันดีซึ่งสร้างขึ้นเมื่อซอฟต์แวร์ได้รับการพัฒนา การพัฒนาตลอดชีวิตของโครงการมากกว่าที่จะเป็นภายหลัง และหลังจากซอฟต์แวร์ทำงานได้ผลตอบรับจากผู้ใช้และเหตุการณ์ใด ๆ ที่อาจนำไปสู่การบาดเจ็บจำเป็นต้องได้รับการพิจารณาเป็นรายบุคคลและโดยรวมเพื่อให้ซอฟต์แวร์ปลอดภัยต่อการใช้งาน Agile สามารถช่วยได้ที่นี่หากมีกระบวนการที่รวดเร็วและปลอดภัยสำหรับการรวมการเปลี่ยนแปลงโดยไม่ทำลายส่วนอื่น ๆ ของระบบซึ่งจำเป็นต้องมีสถาปัตยกรรมที่ดีอีกครั้งและการโต้ตอบการออกแบบที่เข้าใจกันดีซึ่งสร้างขึ้นเมื่อซอฟต์แวร์ได้รับการพัฒนา
ข้อกังวลประการที่สองคือข้อบังคับ ในโลกอุดมคติกฎความปลอดภัยจะใช้กับผลิตภัณฑ์ทั้งหมดที่อาจเป็นอันตรายอย่างเพียงพอและผู้ขายจะสามารถปฏิบัติตามโดยทำสิ่งง่าย ๆ เมื่อเริ่มข้ามเส้น ในทางปฏิบัติแล้วกฎระเบียบทั่วโลกมีความซับซ้อนและรวดเร็วในอุตสาหกรรมนี้หมายความว่าวันหนึ่งคุณสามารถพัฒนาแอป iPhone ขนาดเล็กที่แสดงข้อมูลทางการแพทย์และต่อไปคุณจะต้องปฏิบัติตามมาตรฐาน ISO และ FDA สำหรับ "การจัดการคุณภาพ" ระบบ "หรือ QMS อาจเป็นเรื่องที่น่ากลัวสำหรับ บริษัท ที่ไม่เคยมีระบบบริหารคุณภาพอย่างเป็นทางการในอดีต และความคล่องตัวสามารถทำให้รุนแรงขึ้นได้เพราะคุณอาจเริ่มต้นด้วยแนวคิดผลิตภัณฑ์และผ่านการพัฒนาเชิงวิวัฒนาการเข้าสู่การใช้งานที่มีการควบคุมโดยไม่เจตนา (เช่นการแสดงข้อมูลการวินิจฉัยทางคลินิกแก่ผู้ใช้) เดือนตุลาคม 2554 คำแนะนำของฉันให้กับ บริษัท ใด ๆ ที่พิจารณาการตลาดผลิตภัณฑ์ที่มี "สุขภาพ", "ทางการแพทย์", "การดูแลสุขภาพ" ในชื่อหมวดหมู่คือพวกเขาควรจะมีแผนสำหรับเมื่อผลิตภัณฑ์ที่พวกเขาทำถูกควบคุมโดยผู้ควบคุมอุปกรณ์ทางการแพทย์ ที่นี่อีกครั้งคล่องตัวสามารถช่วยได้เพราะการปฏิบัติเปรียวโดยทั่วไปผลิต (หรือสามารถผลิตได้ง่าย) ผลผลิตที่สอดคล้องกับความพึงพอใจของลูกค้ากฎระเบียบทั้งสำหรับการส่งกวาดล้างก่อนการตลาด (เช่น FDA 510k) การรับรอง (เช่น ISO 13485) และการดำเนินงานหลังตลาด การพัฒนาแบบทดสอบครั้งแรกนั้นเหมาะกับซอฟต์แวร์ทางการแพทย์ การบูรณาการอย่างต่อเนื่องการทดสอบหน่วยอัตโนมัติและข้อมูลเมตา SCRUM sprint สามารถให้หลักฐานที่สมบูรณ์ว่าการจัดการความเสี่ยงและการตรวจสอบที่เหมาะสมนั้นไม่ได้ทำเพียงแค่ในเวลาต่อมา แต่ถูกอบเข้าสู่กระบวนการพัฒนา ในกรณีส่วนใหญ่ฉันคิดว่าเปรียวสร้างสิ่งประดิษฐ์มากกว่า "น้ำตก" บางทีอาจไม่ได้อยู่ในรูปแบบเดียวกัน แต่การแปลงเอาท์พุทเป็นสิ่งที่หน่วยงานกำกับดูแลที่น่าพอใจเป็นปัญหาที่ค่อนข้างเล็กในการแก้ปัญหา
ดังนั้นโดยสรุป ... ใช่แล้วเวอร์จิเนียมีความคล่องตัวในการพัฒนาซอฟต์แวร์ด้านการดูแลสุขภาพ (และอุปกรณ์ทางการแพทย์อื่น ๆ ) เช่นเดียวกับทุกสิ่งที่ว่องไวต้องใช้ความทุ่มเทในการดำเนินการสนับสนุนธุรกิจและความกล้าหาญ
ใช่หนึ่งในสถานที่ของการพัฒนาที่คล่องตัวคือการมีส่วนร่วมของลูกค้า สิ่งนี้มีความสำคัญในระบบและกระบวนการด้านไอทีด้านการดูแลสุขภาพ แผนกไอทีด้านการดูแลสุขภาพจะทำการตัดสินใจได้ดีขึ้นหากตัวแทนลูกค้ามีส่วนเกี่ยวข้องและให้ข้อมูลว่าการตัดสินใจจะส่งผลต่อการดูแลผู้ป่วยอย่างไร
ฉันคิดว่ามันเป็นไปได้ แต่อุตสาหกรรมต้องการเปลี่ยนกระบวนทัศน์ขนาดใหญ่ ฉันอยู่ในปีที่สองของฉันในฐานะนักพัฒนาด้านการดูแลสุขภาพและความไว้วางใจและการจัดระเบียบตัวเองไม่ชัดเจน การดูแลสุขภาพจะได้รับประโยชน์อย่างมากจากการใช้ความคล่องแคล่วอย่างเป็นทางการเนื่องจากมันเป็นความโกลาหลเป็นส่วนใหญ่ด้วยการพัฒนาซ้ำ ๆ ที่เรียกว่า "thrash" และความต้องการการเปลี่ยนแปลงที่ล่าช้าเนื่องจากดีการออกแบบที่ยิ่งใหญ่ไม่ทำงาน
ฉันเข้าใจคำถามของคุณ ตัวอย่างที่ดีของการพัฒนา Agile คือการสร้างเว็บไซต์สำหรับใครบางคน โดยปกติแล้วลูกค้าจะไม่ทราบว่าสิ่งที่เขา / เธอต้องการดังนั้นจึงมีปฏิสัมพันธ์กับลูกค้าจำนวนมาก
ฝ่ายดูแลสุขภาพไอทีอาจดูเหมือนเป็นสาขาวิทยาศาสตร์คอมพิวเตอร์ ด้วยมาตรฐานที่เข้มงวด (DICOM, HL7) ดูเหมือนว่ามีเพียงวิธีเดียวที่จะนำมาใช้ แต่ยังมีความต้องการและการตัดสินใจจำนวนมาก
ในความคิดของฉันไม่ว่าคุณจะทำผลิตภัณฑ์อะไรคุณไม่สามารถกำหนดข้อกำหนดทั้งหมดได้ล่วงหน้าดังนั้นวิธีการพัฒนาซอฟต์แวร์แบบว่องไวจึงเป็นไปได้อย่างดี
ตามที่ระบุไว้คำตอบคือใช่
เมื่อใช้ Agile กับพื้นที่ที่มีการควบคุมหรือมีความเสี่ยงสูงคุณต้องกำหนด "เสร็จสิ้น" ในแต่ละการวนซ้ำเพื่อให้มีการปฏิบัติตามกฎระเบียบและกลยุทธ์การลดความเสี่ยงอื่น ๆ ตัวอย่างเช่นสิ่งนี้อาจต้องมีเอกสาร QA ความต้องการตรวจสอบย้อนกลับการตรวจสอบความปลอดภัยและการดำเนินการอื่น ๆ ที่จะทำให้เสร็จในทุกรอบซ้ำ
ตัวอย่างเช่นมีศิลปะและการปฏิบัติที่ดีสำหรับการใช้แนวทาง Agile กับสภาพแวดล้อมที่มีการควบคุมโดย FDA
คำตอบสั้น ๆ : ใช่ มีบล็อกที่ดีเกี่ยวกับAgile ในสภาพแวดล้อมที่มีความมั่นใจสูงซึ่งให้คำแนะนำบางอย่าง
อย่างไรก็ตามมีการประนีประนอมบางอย่างที่ต้องทำ พิจารณาประกาศเปรียว :
บุคคลและการมีปฏิสัมพันธ์เหนือกระบวนการและเครื่องมือ
ซอฟต์แวร์ที่ทำงานผ่านเอกสารที่ครอบคลุม
การทำงานร่วมกันของลูกค้าในการเจรจาสัญญา
ตอบสนองต่อการเปลี่ยนแปลงมากกว่าการทำตามแผน
หน่วยงานกำกับดูแลให้คุณค่าทางด้านซ้ายมือมากที่สุดเท่าที่ทีมเปรียวทำ แต่พวกเขาต้องการการเน้นทางด้านขวามากกว่าทีมเปรียวทั่วไปที่จะทำ ตัวอย่างเช่น FDA ต้องการให้คุณตรวจสอบกระบวนการและเครื่องมือของคุณขอเอกสารการออกแบบและทดสอบที่ครอบคลุมอย่างเป็นธรรมและต้องมีการวางแผนที่ดี
ในทางกลับกันหลักการความคล่องตัวหลายอย่างเข้ากันได้เป็นอย่างดีในโลกด้านการดูแลสุขภาพรวมถึง:
บางวิชามีความคล่องตัวในธรรมชาติอยู่แล้ว ยกตัวอย่างเช่นการพยาบาลอาศัยวงจรการประเมินผลการประเมินผลการแทรกแซงที่ขึ้นอยู่กับการวนซ้ำหลายครั้งของการวินิจฉัย / การพยากรณ์โรคเพื่อให้บรรลุผลลัพธ์ที่เพิ่มขึ้น
อย่างไรก็ตามมันเป็นความตายร้ายแรงที่จะพยายามที่จะแนะนำให้บริการด้านสุขภาพที่ให้บริการในลักษณะที่เหมาะสมโดยเฉพาะอย่างยิ่งกับการประยุกต์ใช้อินสแตนซ์เดียวของการพัฒนาซอฟต์แวร์ Agile ที่มีต่อเครื่องมือซอฟต์แวร์หรือระบบเพื่อใช้ในการส่งมอบบริการดังกล่าว
AAMIทำงานอย่างแข็งขันในรายงานข้อมูลทางเทคนิคเรื่อง:
AAMI TIR SW1, คำแนะนำในการใช้งานแบบเปรียวในการพัฒนาซอฟต์แวร์อุปกรณ์การแพทย์
ฉันได้ยินมาว่าอาจเผยแพร่ในปี 2012
มันกล่าวถึงการจัดตำแหน่งของหลักการของประกาศ Agile (ดูคำตอบ EpiGrads) กับข้อกำหนดกฎระเบียบกระบวนการทั่วไปและการปฏิบัติผลิตภัณฑ์อื่น ๆ ที่เกี่ยวข้องกับซอฟต์แวร์อุปกรณ์การแพทย์