Bisakah 'Agile' diterapkan ke tim IT Healthcare?

Dapatkah Agile dipekerjakan di bidang seperti IT Layanan Kesehatan, di mana begitu banyak perawatan pasien tergantung pada kualitas dan pengiriman sistem yang tepat waktu?

Ya, pengembangan tangkas benar-benar memiliki peran dalam pengembangan TI Kesehatan. Tidak seorang pun, bukan pengguna akhir, bukan pasien dan tentu saja bukan tim pengembangan dilayani dengan baik oleh proses pengembangan yang dilakukan dengan buruk. Mempertimbangkan beberapa prinsip yang mendasari manifestasi Agile (daftar tanpa malu merobek dari Wikipedia dengan komentar saya):

• Kepuasan pelanggan dengan pengiriman cepat perangkat lunak yang bermanfaat . Kapan ini bukan tujuan?
• Selamat datang perubahan persyaratan, bahkan terlambat dalam pengembangan . IT Healthcare terintegrasi ke dalam bidang yang, meskipun benar-benar dibanjiri dengan teknologi, tidak terlalu fokus pada TI. Potensi sistem yang dirancang untuk "melakukannya dengan benar" langsung kelelawar sangat rendah.
• Perangkat lunak yang berfungsi sering dikirimkan (minggu bukannya bulan) . Sebagai pengguna akhir dari beberapa hal ini, Tuhan akan saya suka ini. Perubahan yang cepat dan bekerja sangat berharga, dan apa yang mengubah Healthcare IT dari "hal yang perlu kita lakukan" menjadi "hal yang mengubah cara saya melakukan pekerjaan saya".
• Perangkat lunak yang berfungsi adalah ukuran utama dari kemajuan . Masuk akal di sebagian besar aplikasi, jadi benar-benar tidak ada alasan itu tidak menjangkau HIT.
• Pembangunan berkelanjutan, mampu mempertahankan kecepatan konstan . Anda melihat ini di seluruh layanan kesehatan, dari pengawasan infeksi hingga HIT hingga fasilitas. Healthcare bukanlah siklus boom-atau-bust, ini adalah drum yang konstan.
• Tutup, kerjasama harian antara pelaku bisnis dan pengembang . Sebagian besar HIT bukan alat pengembang. Ini alat yang dibuat oleh pengembang. Kontak dengan klien adalah, dan harus, kuncinya. Ini juga jauh lebih mudah untuk mendapatkan sistem yang diadopsi jika ia bekerja dan terintegrasi ke dalam alur kerja klien, daripada perlu ditempelkan, ditambal, dll.
• Percakapan tatap muka adalah bentuk komunikasi terbaik (co-location) . Dari interaksi saya dengan dokter, jauh lebih mudah menyelesaikan sendiri, lebih baik menggunakan kertas, daripada cara lainnya.
• Proyek dibangun di sekitar individu yang termotivasi, yang harus dipercaya . Ini adalah sesuatu yang akan membuat hidup Anda lebih baik - jadi ya, itu harus diadopsi;)
• Perhatian terus menerus terhadap keunggulan teknis dan desain yang baik . Lagi-lagi ini adalah salah satu dari "semua orang harus melakukan ini, jadi tentu saja Anda harus" melakukannya. Tetapi pertimbangkan kompleksitas sistem HIT, dan banyak sekali cara mereka akhirnya digunakan, hari demi hari. Sistem yang jelek tidak akan memotongnya.
• Kesederhanaan . Itu harus bekerja di luar kotak. Itu harus bekerja dengan baik, sepanjang waktu, dan dengan cara yang seharusnya. Orang itu idiot. Petugas kesehatan adalah manusia. Karena itu ... Anda tahu sisanya. Kesederhanaan membantu.
• Tim yang mengatur diri sendiri . Yang ini mungkin sedikit lebih melelahkan untuk HIT. Jujur, saya tidak cukup percaya diri untuk mengatakan satu atau lain cara apakah pengaturan diri dalam pengaturan ini baik atau tidak.
• Adaptasi rutin terhadap perubahan keadaan . HIT adalah industri yang aktif dan berkembang dengan beban regulasi yang kompleks dan terus berubah. Mampu beradaptasi sepertinya ide yang bagus.

Diskusi seputar penggunaan Pengembangan Perangkat Lunak Alat Kesehatan Agile dalam pengaturan yang diatur FDA telah ada untuk sementara waktu dan relevan dengan pertanyaan ini. Berikut beberapa alasannya:

1. Pro dan kontra pengembangan Waterfall vs. Iteratif pada dasarnya sama dan perlu dipertimbangkan untuk setiap proyek IT Kesehatan.
2. Sistem kualitas yang diamanatkan FDA (lihat Prinsip Umum Validasi Perangkat Lunak; Pedoman Akhir untuk Industri dan Staf FDA ) untuk pengembangan perangkat lunak perangkat medis yang digunakan adalah standar emas industri. Perlu dicatat bahwa peraturan ini tidak menentukan metodologi pengembangan tertentu. Bagaimanapun, kualitas perangkat lunak TI Kesehatan akan jauh meningkat jika praktik terbaik ini diikuti oleh semua.
3. Sebagian besar pengembangan perangkat lunak TI Heath saat ini tidak beroperasi di bawah standar peraturan FDA ini. Karena hambatan untuk interoperabilitas perangkat medis terus turun, khususnya untuk platform seluler, ini kemungkinan akan berubah - lihat FDA Addresses Mobile Medical Apps .
4. Juga, jika Anda mengembangkan perangkat lunak IT Kesehatan komersial, Anda harus bertanya pada diri sendiri apakah Anda membuat sistem data perangkat medis (MDDS): Apakah Produk Saya MDDS?

Jawaban singkatnya adalah "Ya". Jawaban yang lebih panjang tetapi lebih akurat adalah "Jika Anda menganggapnya serius."

Ada beberapa tema yang perlu diingat, yang ingin saya pisahkan menjadi masalah terkait (a) keselamatan pasien & kualitas produk, dan (b) regulasi industri.

Di sisi keamanan dan kualitas, perlu diingat bahwa membuat perangkat lunak yang aman itu sulit. Beberapa programmer yang baik dengan pengetahuan domain bisa mengeluarkan perangkat lunak yang sangat berguna yang cukup aman. Jika mereka adalah bagian dari penyebaran dalam pengaturan klinis lokal, dan dapat terus merespons dan menyesuaikan dengan peristiwa selama penyebaran dan penggunaan perangkat lunak, perangkat lunak mungkin memberikan nilai, menyelamatkan atau meningkatkan kehidupan dengan hanya beberapa cedera atau kematian terkait dengan kesalahan penggunaan atau bug perangkat lunak. Tetapi perangkat lunak akan membutuhkan programmer untuk berada di sana, sepanjang waktu, merespons, mengembangkan perangkat lunak secara bersamaan saat penggunaan perangkat lunak berkembang. Ini bukan proses scalable dan ketika programmer mati atau bosan sistem dapat dengan mudah menjadi sangat berbahaya dengan sangat cepat. Untuk meningkatkan hasil ini dan membuat perangkat lunak yang aman, ada langkah-langkah proses pengembangan penting yang perlu diambil saat perangkat lunak dikembangkan. Pengantar "out of the box" yang bagus untuk ini dapat ditemukan dalam standar internasional untuk pengembangan perangkat perangkat medis, ISO / IEC 62304. Konsep utama adalah manajemen risiko keselamatan di semua tahap - selama analisis kasus penggunaan dan pengembangan cerita, persyaratan Penjelasan, desain sistem dan arsitektur, implementasi, pengujian unit dan integrasi. Menjadi lincah tidak akan membuat pekerjaan ini hilang, atau menjadi kurang sulit, tetapi dengan berfokus pada penciptaan nilai dan menghilangkan pekerjaan (seperti fitur yang tidak dibutuhkan, atau tes verifikasi / siklus perbaikan yang berlebihan) yang tidak menciptakan nilai, pengembangan tangkas dapat memungkinkan tim untuk mengintegrasikan pekerjaan ini ke dalam pengembangan, menghasilkan perangkat lunak yang lebih aman dikembangkan pada saat yang sama. Praktik pengembangan berulang yang biasa digunakan oleh tim tangkas sangat cocok untuk menyelesaikan pekerjaan manajemen risiko keselamatan, berkembang sepanjang umur proyek daripada menjadi renungan. Dan setelah perangkat lunak itu operasional, umpan balik dari pengguna dan setiap peristiwa yang bahkan berpotensi menyebabkan cedera perlu dipertimbangkan, secara individu, dan secara agregat, untuk menjaga perangkat lunak itu aman untuk digunakan. Agile dapat membantu di sini jika menyediakan proses jalur cepat dan aman untuk memasukkan perubahan tanpa merusak bagian lain sistem - yang pada gilirannya sekali lagi membutuhkan arsitektur yang baik dan interaksi desain yang dipahami dengan baik yang dibuat ketika perangkat lunak dikembangkan. berkembang sepanjang kehidupan proyek daripada menjadi renungan. Dan setelah perangkat lunak itu operasional, umpan balik dari pengguna dan setiap peristiwa yang bahkan berpotensi menyebabkan cedera perlu dipertimbangkan, secara individu, dan secara agregat, untuk menjaga perangkat lunak itu aman untuk digunakan. Agile dapat membantu di sini jika menyediakan proses jalur cepat dan aman untuk memasukkan perubahan tanpa merusak bagian lain sistem - yang pada gilirannya sekali lagi membutuhkan arsitektur yang baik dan interaksi desain yang dipahami dengan baik yang dibuat ketika perangkat lunak dikembangkan. berkembang sepanjang kehidupan proyek daripada menjadi renungan. Dan setelah perangkat lunak itu operasional, umpan balik dari pengguna dan setiap peristiwa yang bahkan berpotensi menyebabkan cedera perlu dipertimbangkan, secara individu, dan secara agregat, untuk menjaga perangkat lunak itu aman untuk digunakan. Agile dapat membantu di sini jika menyediakan proses jalur cepat dan aman untuk memasukkan perubahan tanpa merusak bagian lain sistem - yang pada gilirannya sekali lagi membutuhkan arsitektur yang baik dan interaksi desain yang dipahami dengan baik yang dibuat ketika perangkat lunak dikembangkan.

Kekhawatiran kedua adalah regulasi. Di dunia yang ideal, peraturan keselamatan akan berlaku untuk semua produk yang dapat cukup berbahaya, dan vendor akan dapat mematuhi dengan melakukan beberapa hal sederhana begitu mereka mulai melewati batas. Dalam praktiknya, peraturan global sangat kompleks dan bergerak cepat dalam industri ini, yang berarti bahwa suatu hari Anda dapat mengembangkan aplikasi iPhone kecil yang menunjukkan beberapa data medis, dan selanjutnya Anda diharapkan untuk mematuhi standar ISO dan FDA untuk "manajemen mutu sistem ", atau QMS. Itu bisa menakutkan bagi perusahaan yang belum memiliki SMM formal di masa lalu. Dan lincah dapat memperburuk ini karena Anda mungkin mulai dengan konsep produk, dan melalui pengembangan evolusi tanpa disadari masuk ke dalam penggunaan yang direncanakan yang diatur (seperti menampilkan data diagnosis klinis kepada pengguna). Ini Oktober 2011; saran saya kepada perusahaan mana pun yang merenungkan pemasaran produk yang memiliki "kesehatan", "medis", "kesehatan" dalam nama kategori adalah bahwa mereka harus memiliki rencana ketika produk yang mereka buat diatur oleh satu atau lebih regulator perangkat medis di seluruh dunia. Di sini lagi tangkas dapat membantu, karena praktik tangkas umumnya menghasilkan (atau dengan mudah bisa menghasilkan) keluaran yang sesuai untuk memuaskan pelanggan regulatori baik untuk pengajuan izin pra-pasar (seperti FDA 510k), sertifikasi (seperti ISO 13485), dan operasi pasca-pasar. Pengembangan tes pertama cocok dengan perangkat lunak medis. Integrasi yang berkelanjutan, pengujian unit otomatis, dan metadata sprint SCRUM dapat memberikan bukti objektif yang lengkap bahwa manajemen risiko dan verifikasi yang tepat dilakukan tidak hanya sebagai renungan tetapi dimasukkan ke dalam proses pengembangan. Dalam kebanyakan kasus saya pikir gesit menghasilkan lebih banyak artefak daripada "air terjun", mungkin tidak dalam bentuk yang sama. Tetapi konversi output menjadi sesuatu yang memuaskan regulator adalah masalah yang relatif kecil untuk dipecahkan.

Jadi secara ringkas ... ya Virginia, ada lincah untuk pengembangan perangkat lunak TI (dan perangkat medis lainnya) kesehatan. Seperti semua hal gesit, dibutuhkan dedikasi untuk memproses, mendukung bisnis, dan keberanian.

Ya, salah satu tempat pengembangan tangkas adalah keterlibatan pelanggan. Ini sangat penting dalam sistem dan proses TI perawatan kesehatan. Departemen IT Healthcare akan membuat keputusan yang lebih baik jika perwakilan pelanggan terlibat dan memberikan masukan tentang bagaimana keputusan itu akan memengaruhi perawatan pasien.

Saya pikir itu mungkin, tetapi industri ini membutuhkan perubahan paradigma yang besar. Saya berada di tahun kedua sebagai pengembang perawatan kesehatan, dan kepercayaan serta pengorganisasian diri tidak terlihat di mana pun. Healthcare akan mendapat banyak manfaat dari mengadopsi secara tangkas, karena bagaimanapun itu sebagian besar adalah kekacauan, dengan pengembangan berulang yang disebut "thrash" dan persyaratan yang terlambat diubah karena, well, desain besar di muka tidak bekerja.

Saya mengerti pertanyaan Anda. Contoh pengembangan Agile yang bagus adalah membangun situs web untuk seseorang. Biasanya seorang pelanggan tidak tahu persis apa yang dia inginkan, jadi ada banyak interaksi dengan pelanggan.

Kesehatan IT mungkin tampak seperti bidang yang sudah ditentukan sebelumnya dalam ilmu komputer; dengan standar yang ketat (DICOM, HL7) sepertinya hanya ada satu cara untuk mengimplementasikannya, tetapi ada juga banyak preferensi dan pengambilan keputusan.

Menurut pendapat saya, produk apa pun yang Anda buat, Anda tidak dapat menentukan SEMUA persyaratan sebelumnya, sehingga metode pengembangan perangkat lunak yang gesit bekerja dengan sangat baik.

Sebagaimana dicatat, jawabannya adalah ya.

Saat menerapkan Agile ke area yang diatur atau berisiko tinggi Anda harus mendefinisikan "Selesai" pada setiap iterasi sedemikian rupa sehingga kepatuhan terhadap peraturan dan strategi mitigasi risiko lainnya dimasukkan. Misalnya, ini mungkin memerlukan dokumentasi QA, persyaratan penelusuran, audit keamanan dan tindakan lainnya harus diselesaikan pada setiap iterasi.

Ada seni dan praktik yang baik, misalnya, untuk penerapan pendekatan Agile ke lingkungan yang diatur FDA.

Jawaban singkatnya: Ya. Ada blog yang bagus tentang Agile di High-Assurance Environments yang memberikan beberapa tips.

Namun, ada beberapa kompromi yang perlu dilakukan. Pertimbangkan Agile Manifesto :

Individu dan interaksi atas proses dan alat

Bekerja dengan perangkat lunak melalui dokumentasi yang komprehensif

Kolaborasi pelanggan atas negosiasi kontrak

Menanggapi perubahan setelah mengikuti rencana

Badan pengawas menilai sisi kiri sama seperti tim tangkas, tetapi mereka membutuhkan lebih banyak tekanan di sisi kanan daripada tim tangkas khas biasanya. FDA, misalnya, mengharuskan Anda memvalidasi proses dan alat Anda, meminta desain yang cukup komprehensif dan dokumentasi pengujian, dan tentunya membutuhkan perencanaan yang baik.

Di sisi lain, banyak prinsip gesit sangat cocok dengan dunia perawatan kesehatan, termasuk:

• Pemrograman TDD dan Pair - meningkatkan kualitas
• Umpan Balik Pelanggan Yang Ketat - loop awal validasi bagus
• Perencanaan berulang - badan pengawas adalah semua tentang perencanaan

Beberapa disiplin sudah sifatnya gesit. Keperawatan, misalnya, bergantung pada siklus 'penilaian-evaluasi-perencanaan-intervensi' yang bergantung pada beberapa iterasi diagnosis / prognosis untuk secara bertahap mencapai hasil akhir.

Namun, itu akan menjadi penggabungan yang fatal untuk mencoba menyarankan bahwa layanan perawatan kesehatan yang disediakan sedemikian rupa secara khusus cocok untuk aplikasi pada dasarnya satu contoh pengembangan perangkat lunak Agile terhadap perangkat perangkat lunak atau sistem untuk digunakan dalam pemberian layanan tersebut.

AAMI secara aktif mengerjakan Laporan Informasi Teknis berjudul:
AAMI TIR SW1, Pedoman penggunaan praktik lincah dalam pengembangan perangkat lunak perangkat medis.

Saya pernah mendengar bahwa itu mungkin diterbitkan pada tahun 2012.

Ini membahas penyelarasan prinsip-prinsip Agile Manifesto (lihat jawaban EpiGrads) dengan persyaratan peraturan, proses khas, dan kepraktisan produk lainnya yang terkait dengan perangkat lunak perangkat medis.