'Agile' có thể được áp dụng cho các nhóm IT chăm sóc sức khỏe không?

Agile có thể được tuyển dụng trong một lĩnh vực như Chăm sóc sức khỏe CNTT hay không, nơi có rất nhiều dịch vụ chăm sóc bệnh nhân phụ thuộc vào chất lượng và việc cung cấp kịp thời các hệ thống?

Có, phát triển nhanh hoàn toàn có vai trò trong phát triển CNTT chăm sóc sức khỏe. Không ai, không phải người dùng cuối, không phải bệnh nhân và chắc chắn không phải nhóm phát triển được phục vụ tốt bởi một quy trình phát triển được thực hiện kém. Xem xét một số nguyên tắc dưới bản tuyên ngôn Agile (danh sách được xé ra một cách đáng xấu hổ từ Wikipedia với lời bình luận của tôi):

• Sự hài lòng của khách hàng bằng cách cung cấp nhanh chóng các phần mềm hữu ích . Khi nào đây không phải là một mục tiêu?
• Chào mừng các yêu cầu thay đổi, thậm chí muộn trong phát triển . Chăm sóc sức khỏe CNTT tích hợp vào một lĩnh vực, trong khi hoàn toàn tràn ngập công nghệ, không đặc biệt tập trung vào CNTT. Tiềm năng cho một hệ thống được thiết kế để "làm cho đúng" ngay lập tức là rất thấp.
• Phần mềm làm việc được phân phối thường xuyên (tuần chứ không phải tháng) . Là người dùng cuối của một số thứ này, chúa sẽ thích nó. Những thay đổi nhanh chóng, hiệu quả là vô giá, và điều gì biến CNTT CNTT từ "điều chúng ta cần làm" thành "điều đó thay đổi cách tôi làm công việc của mình".
• Phần mềm làm việc là thước đo chính của sự tiến bộ . Có ý nghĩa trong hầu hết các ứng dụng, vì vậy thực sự không có lý do gì nó không kéo dài tới HIT.
• Phát triển bền vững, có thể duy trì tốc độ không đổi . Bạn thấy điều này trên toàn bộ chăm sóc sức khỏe, từ giám sát nhiễm trùng đến HIT đến các cơ sở. Chăm sóc sức khỏe không phải là một chu kỳ bùng nổ, mà là tiếng trống liên tục.
• Đóng, hợp tác hàng ngày giữa người kinh doanh và nhà phát triển . Hầu hết HIT không phải là một công cụ dành cho nhà phát triển. Đó là một công cụ được tạo ra bởi các nhà phát triển. Liên hệ với khách hàng là, và nên là, chính. Cũng dễ dàng hơn nhiều để có được một hệ thống được chấp nhận nếu nó hoạt động và tích hợp vào quy trình làm việc của khách hàng, thay vì cần phải xử lý, vá lỗi, v.v.
• Trò chuyện trực tiếp là hình thức giao tiếp tốt nhất (đồng địa điểm) . Từ sự tương tác của tôi với các bác sĩ, đó là cách dễ dàng hơn để có được công cụ thực hiện trong người, tốt hơn với tấm lót giấy, hơn bất kỳ cách nào khác.
• Các dự án được xây dựng xung quanh các cá nhân có động lực, những người nên được tin tưởng . Đây là một cái gì đó sẽ làm cho cuộc sống của bạn tốt hơn - vì vậy, nó nên được thông qua;)
• Liên tục chú ý đến sự xuất sắc kỹ thuật và thiết kế tốt . Đây lại là một trong những điều "mọi người nên làm điều này, vì vậy tất nhiên bạn nên làm". Nhưng hãy xem xét sự phức tạp của các hệ thống HIT và vô số cách mà chúng cuối cùng được sử dụng, ngày này qua ngày khác. Một hệ thống kém chất lượng sẽ không cắt giảm.
• Đơn giản . Nó sẽ làm việc ra khỏi hộp. Nó nên hoạt động tốt, mọi lúc, và theo cách nó được yêu cầu. Mọi người là những kẻ ngốc. Nhân viên y tế là người. Do đó ... bạn biết phần còn lại. Đơn giản giúp.
• Các đội tự tổ chức . Điều này có thể là một chút kéo dài cho HIT. Thành thật mà nói, tôi không đủ tự tin để nói cách này hay cách khác cho dù việc tự tổ chức trong cài đặt này có tốt hay không.
• Thích nghi thường xuyên với hoàn cảnh thay đổi . HIT là một ngành công nghiệp đang phát triển, tích cực với những gánh nặng pháp lý phức tạp, thay đổi. Có thể thích nghi có vẻ như một ý tưởng tốt.

Các cuộc thảo luận xung quanh việc sử dụng Phát triển phần mềm thiết bị y tế Agile trong môi trường do FDA quản lý đã diễn ra trong một thời gian và có liên quan đến câu hỏi này. Dưới đây là một số lý do tại sao:

1. Các ưu và nhược điểm phát triển của Thác nước so với lặp đi lặp lại về cơ bản là giống nhau và cần được xem xét cho bất kỳ dự án CNTT Y tế nào.
2. Các hệ thống chất lượng bắt buộc của FDA (xem Nguyên tắc chung về Xác thực phần mềm; Hướng dẫn cuối cùng cho Nhân viên Công nghiệp và FDA ) để phát triển phần mềm thiết bị y tế được sử dụng là tiêu chuẩn vàng của ngành. Cần lưu ý rằng các quy định này không áp đặt bất kỳ phương pháp phát triển cụ thể nào. Trong mọi trường hợp, chất lượng của phần mềm IT CNTT sẽ được cải thiện rất nhiều nếu tất cả các hoạt động tốt nhất này được tuân thủ.
3. Hầu hết sự phát triển phần mềm Heath IT hiện không hoạt động theo các tiêu chuẩn quy định này của FDA. Khi các rào cản về khả năng tương tác của thiết bị y tế tiếp tục giảm, đặc biệt là các nền tảng di động, điều này có thể sẽ thay đổi - xem FDA Địa chỉ ứng dụng y tế di động .
4. Ngoài ra, nếu bạn đang phát triển phần mềm IT CNTT thương mại, bạn phải tự hỏi mình có đang tạo hệ thống dữ liệu thiết bị y tế (MDDS) không: Sản phẩm của tôi có phải là MDDS không?

Câu trả lời ngắn gọn là có". Một câu trả lời dài hơn nhưng chính xác hơn là "Nếu bạn thực hiện nghiêm túc".

Có một vài chủ đề cần lưu ý, mà tôi muốn tách thành các mối quan tâm liên quan đến (a) chất lượng sản phẩm & an toàn của bệnh nhân và (b) quy định của ngành.

Về mặt an toàn và chất lượng, hãy nhớ rằng làm cho phần mềm an toàn là khó khăn. Một vài lập trình viên giỏi với một số kiến ​​thức về miền có thể tạo ra phần mềm cực kỳ hữu ích, khá an toàn. Nếu chúng là một phần của việc triển khai trong môi trường lâm sàng tại địa phương và có thể tiếp tục phản hồi và điều chỉnh các sự kiện trong quá trình triển khai và sử dụng phần mềm, phần mềm có thể cung cấp giá trị, cứu hoặc cải thiện cuộc sống chỉ với một vài thương tích hoặc tử vong liên quan đến lỗi sử dụng hoặc lỗi phần mềm. Nhưng phần mềm sẽ yêu cầu các lập trình viên phải ở đó, mọi lúc, trả lời, đồng phát triển phần mềm khi việc sử dụng phần mềm phát triển. Đây không phải là một quá trình có thể mở rộng và khi các lập trình viên chết hoặc chán, hệ thống có thể dễ dàng trở nên rất nguy hiểm rất nhanh. Để cải thiện các kết quả này và làm cho phần mềm an toàn, có các bước quy trình phát triển quan trọng cần được thực hiện trong khi phần mềm được phát triển. Có thể tìm thấy phần giới thiệu "ngoài lề" tốt trong các tiêu chuẩn quốc tế về phát triển phần mềm thiết bị y tế, ISO / IEC 62304. Khái niệm chính là quản lý rủi ro an toàn ở tất cả các giai đoạn - trong quá trình phân tích ca bệnh và sử dụng câu chuyện làm sáng tỏ, thiết kế hệ thống và kiến ​​trúc, thực hiện, thử nghiệm đơn vị và tích hợp. Nhanh nhẹn sẽ không làm cho bất kỳ công việc này biến mất, hoặc ít khó khăn hơn, nhưng bằng cách tập trung vào việc tạo giá trị và loại bỏ công việc (như các tính năng không cần thiết hoặc chu trình kiểm tra / sửa lỗi quá mức) không tạo ra giá trị, có thể phát triển nhanh cho phép một nhóm tích hợp công việc này vào phát triển, dẫn đến phần mềm an toàn hơn được phát triển cùng một lúc. Các thực tiễn phát triển lặp thường được sử dụng bởi các nhóm nhanh nhẹn rất phù hợp để hoàn thành công việc quản lý rủi ro an toàn, phát triển trong suốt vòng đời của dự án thay vì suy nghĩ lại. Và sau khi phần mềm hoạt động, phản hồi từ người dùng và bất kỳ sự kiện nào thậm chí có khả năng dẫn đến thương tích cần phải được xem xét, riêng lẻ và tổng hợp, để giữ cho phần mềm an toàn khi sử dụng. Agile có thể giúp đỡ ở đây nếu nó cung cấp một quy trình nhanh chóng, an toàn để kết hợp các thay đổi mà không phá vỡ các phần khác của hệ thống - điều này một lần nữa đòi hỏi một kiến ​​trúc tốt và các tương tác thiết kế được hiểu rõ được tạo ra khi phần mềm được phát triển. phát triển trong suốt cuộc đời của dự án chứ không phải là một suy nghĩ sau. Và sau khi phần mềm hoạt động, phản hồi từ người dùng và bất kỳ sự kiện nào thậm chí có khả năng dẫn đến thương tích cần phải được xem xét, riêng lẻ và tổng hợp, để giữ cho phần mềm an toàn khi sử dụng. Agile có thể giúp đỡ ở đây nếu nó cung cấp một quy trình nhanh chóng, an toàn để kết hợp các thay đổi mà không phá vỡ các phần khác của hệ thống - điều này một lần nữa đòi hỏi một kiến ​​trúc tốt và các tương tác thiết kế được hiểu rõ được tạo ra khi phần mềm được phát triển. phát triển trong suốt cuộc đời của dự án chứ không phải là một suy nghĩ sau. Và sau khi phần mềm hoạt động, phản hồi từ người dùng và bất kỳ sự kiện nào thậm chí có khả năng dẫn đến thương tích cần phải được xem xét, riêng lẻ và tổng hợp, để giữ cho phần mềm an toàn khi sử dụng. Agile có thể giúp đỡ ở đây nếu nó cung cấp một quy trình nhanh chóng, an toàn để kết hợp các thay đổi mà không phá vỡ các phần khác của hệ thống - điều này một lần nữa đòi hỏi một kiến ​​trúc tốt và các tương tác thiết kế được hiểu rõ được tạo ra khi phần mềm được phát triển.

Mối quan tâm thứ hai là quy định. Trong một thế giới lý tưởng, các quy định an toàn sẽ được áp dụng cho tất cả các sản phẩm có thể đủ nguy hiểm và nhà cung cấp sẽ có thể tuân thủ bằng cách thực hiện một số điều đơn giản sau khi họ bắt đầu vượt qua. Trong thực tế, các quy định toàn cầu rất phức tạp và chuyển động nhanh trong ngành này, có nghĩa là một ngày nào đó bạn có thể phát triển một ứng dụng iPhone nhỏ hiển thị một số dữ liệu y tế và tiếp theo bạn sẽ tuân thủ các tiêu chuẩn ISO và FDA về "quản lý chất lượng hệ thống ", hoặc QMS. Điều đó có thể đáng sợ đối với các công ty chưa có QMS chính thức trong quá khứ. Và nhanh nhẹn có thể làm trầm trọng thêm điều này bởi vì bạn có thể bắt đầu với một khái niệm sản phẩm và thông qua sự phát triển tiến hóa vô tình đưa vào sử dụng theo quy định (như hiển thị dữ liệu chẩn đoán lâm sàng cho người dùng). Đó là tháng 10 năm 2011; Lời khuyên của tôi cho bất kỳ công ty nào dự định tiếp thị một sản phẩm có "sức khỏe", "y tế", "chăm sóc sức khỏe" trong tên danh mục là họ nên có kế hoạch khi sản phẩm họ sản xuất trở thành quy định bởi một hoặc nhiều cơ quan quản lý thiết bị y tế trên toàn thế giới. Ở đây một lần nữa, agile có thể giúp đỡ, bởi vì các thực tiễn nhanh thường tạo ra các đầu ra tuân thủ (hoặc dễ dàng có thể tạo ra) để đáp ứng khách hàng theo quy định cả về đệ trình giải phóng mặt bằng trước thị trường (như FDA 510k), chứng nhận (như ISO 13485) và hoạt động sau thị trường. Phát triển thử nghiệm đầu tiên phù hợp ngay với phần mềm y tế. Tích hợp liên tục, kiểm tra đơn vị tự động và siêu dữ liệu chạy nước rút SCRUM có thể cung cấp bằng chứng khách quan hoàn chỉnh rằng quản lý rủi ro và xác minh đúng được thực hiện không chỉ là một suy nghĩ mà còn được đưa vào quá trình phát triển. Trong hầu hết các trường hợp, tôi nghĩ rằng agile tạo ra nhiều tạo tác hơn là "thác nước", có lẽ không ở dạng tương tự. Nhưng việc chuyển đổi các đầu ra thành một cái gì đó thỏa mãn các cơ quan quản lý là một vấn đề tương đối nhỏ để giải quyết.

Vì vậy, tóm lại ... có Virginia, có sự phát triển phần mềm CNTT (và thiết bị y tế khác) nhanh nhẹn. Giống như tất cả mọi thứ nhanh nhẹn, cần có sự cống hiến để xử lý, hỗ trợ kinh doanh và can đảm.

Vâng, một trong những tiền đề của sự phát triển nhanh là sự tham gia của khách hàng. Điều này là rất quan trọng trong các hệ thống và quy trình CNTT chăm sóc sức khỏe. Bộ phận CNTT chăm sóc sức khỏe sẽ đưa ra quyết định tốt hơn nếu có đại diện khách hàng tham gia và đưa ra ý kiến ​​về cách các quyết định sẽ ảnh hưởng đến việc chăm sóc bệnh nhân.

Tôi nghĩ rằng nó có thể, nhưng ngành công nghiệp cần một sự thay đổi mô hình rất lớn. Tôi đang học năm thứ hai với tư cách là một nhà phát triển chăm sóc sức khỏe, và sự tin tưởng và tự tổ chức không ở đâu rõ ràng. Chăm sóc sức khỏe sẽ được hưởng lợi rất nhiều từ việc chính thức áp dụng nhanh nhẹn, vì dù sao nó cũng là sự hỗn loạn, với sự phát triển lặp đi lặp lại được gọi là "thrash" và yêu cầu thay đổi muộn bởi vì, dù sao, thiết kế lớn không hoạt động.

Tôi hiểu câu hỏi của bạn. Một ví dụ điển hình về phát triển Agile là xây dựng một trang web cho một ai đó. Thông thường một khách hàng không biết chính xác những gì anh ấy / cô ấy muốn, vì vậy có rất nhiều tương tác với khách hàng.

Chăm sóc sức khỏe CNTT có vẻ như là một lĩnh vực được xác định trước trong khoa học máy tính; với các tiêu chuẩn nghiêm ngặt (DICOM, HL7) có vẻ như chỉ có một cách để thực hiện chúng, nhưng cũng có rất nhiều ưu tiên và ra quyết định.

Theo tôi, bất cứ sản phẩm nào bạn đang làm, bạn đều không thể xác định TẤT CẢ các yêu cầu trước thời hạn, vì vậy phương pháp phát triển phần mềm linh hoạt hoạt động rất độc đáo.

Như đã lưu ý, câu trả lời là có.

Khi áp dụng Agile cho các khu vực có quy định hoặc rủi ro cao, bạn phải xác định "Hoàn thành" tại mỗi lần lặp sao cho tuân thủ quy định và các chiến lược giảm thiểu rủi ro khác. Ví dụ, điều này có thể yêu cầu tài liệu QA, yêu cầu truy xuất nguồn gốc, kiểm toán bảo mật và các hành động khác phải được hoàn thành trên mỗi lần lặp.

Chẳng hạn, có nghệ thuật và thực hành tốt để áp dụng các phương pháp Agile vào môi trường do FDA quản lý.

Câu trả lời ngắn gọn: Có. Có một blog tốt về Agile trong môi trường đảm bảo cao cung cấp một số lời khuyên.

Tuy nhiên, có một số thỏa hiệp cần phải được thực hiện. Hãy xem xét Tuyên ngôn Agile :

Các cá nhân và tương tác qua các quy trình và công cụ

Phần mềm làm việc trên tài liệu toàn diện

Hợp tác khách hàng qua đàm phán hợp đồng

Đáp ứng để thay đổi theo kế hoạch

Các cơ quan quản lý coi trọng phía bên trái nhiều như các đội nhanh nhẹn, nhưng họ yêu cầu nhấn mạnh vào phía bên phải nhiều hơn so với một đội nhanh nhẹn thông thường sẽ làm. Ví dụ, FDA yêu cầu bạn xác nhận các quy trình và công cụ của mình, yêu cầu tài liệu thử nghiệm và thiết kế khá toàn diện và chắc chắn cần có một kế hoạch tốt.

Mặt khác, nhiều nguyên tắc nhanh nhẹn rất phù hợp với thế giới chăm sóc sức khỏe, bao gồm:

• Lập trình TDD và Ghép đôi - tăng chất lượng
• Vòng lặp phản hồi khách hàng chặt chẽ - xác nhận sớm là tuyệt vời
• Lập kế hoạch lặp lại - cơ quan quản lý là tất cả về kế hoạch

Một số môn học đã nhanh nhẹn trong tự nhiên. Điều dưỡng, ví dụ, dựa vào một chu trình 'đánh giá-đánh giá-lập kế hoạch-can thiệp' phụ thuộc vào nhiều lần chẩn đoán / tiên lượng để tăng dần kết quả cuối cùng.

Tuy nhiên, sẽ là một sự kết hợp nghiêm trọng khi cố gắng đề xuất rằng các dịch vụ chăm sóc sức khỏe được cung cấp theo cách đó đặc biệt phù hợp với một ứng dụng đơn lẻ về phát triển phần mềm Agile đối với một công cụ hoặc hệ thống phần mềm để sử dụng trong việc cung cấp dịch vụ nói trên.

AAMI đang tích cực làm việc trên Báo cáo thông tin kỹ thuật có tên:
AAMI TIR SW1, Hướng dẫn sử dụng các thực hành nhanh trong việc phát triển phần mềm thiết bị y tế.

Tôi đã nghe nói rằng nó có thể được xuất bản vào năm 2012.

Nó thảo luận về sự liên kết của các nguyên tắc của Tuyên ngôn Agile (xem câu trả lời của EpiGrads) với các yêu cầu quy định, quy trình điển hình và thực tiễn sản phẩm khác liên quan đến phần mềm thiết bị y tế.