'ITile' Healthcare IT ekiplerine uygulanabilir mi?

Agile, Healthcare IT gibi bir alanda kullanılabilir mi, burada çok fazla hasta bakımı sistemin kalitesine ve zamanında teslimine bağlıdır?

Evet, çevik gelişimin Sağlık Bilgi Teknolojileri gelişiminde kesinlikle bir rolü var. Hiç kimse, son kullanıcı değil, hasta değil ve kesinlikle geliştirme ekibinin olmadığı kötü bir gelişim süreci tarafından iyi bir şekilde yerine getirilemez. Çevik manifesto'nun temelini oluşturan ilkelerden bazılarını göz önünde bulundurarak (liste, yorumumla utanmadan Vikipedi'den ayrılmıştı):

• Yararlı yazılımların hızlı teslimatı ile müşteri memnuniyeti . Bu ne zaman bir amaç değil?
• Gelişmekte olan geç bile, değişen gereksinimleri karşılayın . Sağlık hizmetleri bilişim teknolojisi, tamamen teknoloji ile dolu olsa da özellikle bilişim odaklı olmayan bir alana entegre olur. Bir sistemin yarasadan hemen '' doğru '' çıkması için tasarlanan potansiyel oldukça düşük.
• Çalışma yazılımı sık sık verilir (aylar değil haftalar) . Bunlardan bazılarının son kullanıcısı olarak, Tanrı buna bayılırdı. Hızlı, çalışma değişiklikleri paha biçilmezdir ve Healthcare IT ürününü "yapmamız gereken şey" den "işimi yapma biçimimi değiştiren şey" e dönüştürür.
• Çalışan yazılım, ilerlemenin temel ölçüsüdür . Çoğu uygulamada anlamlıdır, dolayısıyla HIT'e yayılmaması için hiçbir neden yoktur.
• Sürdürülebilir gelişim, sabit bir hızda devam edebiliyor . Bunu enfeksiyon gözetiminden HIT'ye ve tesislere kadar tüm sağlık hizmetlerinde görüyorsunuz. Sağlık hizmetleri bir patlama ya da büstü döngüsü değil, sürekli bir davul atışıdır.
• İş adamları ve geliştiriciler arasında yakın, günlük işbirliği . Çoğu HIT bir geliştirici aracı değildir. Geliştiriciler tarafından yapılan bir araçtır. Müşteriyle iletişim kurmak çok önemlidir. Ayrıca, izlenmesi, yamalanması vb. Gerekmek yerine çalışır ve müşterilerin iş akışına entegre edilirse, bir sistemin benimsenmesi çok daha kolaydır.
• Yüz yüze konuşma, en iyi iletişim şeklidir (ortak konum) . Klinisyenler ile benim etkileşimden, bu kadar yolu şeyler başka bir şekilde daha tercihen not kağıtları ile bizzat halletmek daha kolay.
• Projeler, güvenilmesi gereken motive olmuş bireyler etrafında inşa edilir . Bu hale getirecek bir şeydir sizin daha iyi bir yaşam - yani evet, kabul edilmelidir;)
• Teknik mükemmellik ve iyi tasarıma sürekli dikkat . Bu yine, "herkes bunu yapmalı, tabii ki yapmalı" şeyinden biri. Ancak, HIT sistemlerinin karmaşıklığını ve gün geçtikçe gün geçtikçe kullanılmalarına neden olan sayısız yolu düşünün. Ayakkabılı bir sistem onu ​​kesmeyecek.
• Basitlik . Kutunun dışında çalışmalı. Her zaman ve olması gerektiği şekilde iyi çalışması gerekir. İnsanlar aptaldır. Sağlık çalışanları insandır. Bu yüzden ... gerisini biliyorsun. Sadelik yardımcı olur.
• Kendini organize eden takımlar . Bu, HIT için biraz daha fazla olabilir. Dürüst olmak gerekirse, bu ortamda öz-örgütlenmenin iyi ya da iyi olup olmadığını bir şekilde söyleyebilecek kadar kendimden emin değilim.
• Değişen koşullara düzenli adaptasyon . HIT karmaşık, değişen düzenleyici yüklere sahip aktif, büyüyen bir endüstridir. Uyum sağlayabilmek iyi bir fikir gibi görünüyor.

Çevik Tıbbi Cihaz Yazılım Geliştirme'nin FDA tarafından düzenlenmiş bir ortamda kullanılmasını çevreleyen tartışmalar bir süredir devam ediyor ve bu soruyla ilgili. İşte nedenlerinden bazıları:

1. Şelale vs Yinelemeli gelişim artıları ve eksileri esas olarak aynıdır ve herhangi bir Sağlık Bilgi Teknolojisi projesi için dikkate alınması gerekir.
2. Kullanılan tıbbi cihaz yazılımı geliştirme için FDA zorunlu kalite sistemleri (bkz . Yazılım Doğrulamanın Genel Prensipleri; Endüstri ve FDA Personeli İçin Son Rehberlik ) endüstri altın standardıdır. Bu düzenlemelerin herhangi bir özel gelişme metodolojisini belirlemediğine dikkat edilmelidir. Her durumda, bu en iyi uygulamaları herkes takip ederse, Sağlık BT yazılımının kalitesi büyük ölçüde geliştirilecektir.
3. Çoğu Heath IT yazılımı geliştirme şu anda bu FDA yönetmelik standartları kapsamında işlememektedir. Tıbbi cihazlarla birlikte çalışabilirlik önündeki engeller düşmeye devam ettikçe, özellikle mobil platformlar için, bu muhtemelen değişecek - bkz. FDA Adresleri Mobil Tıbbi Uygulamalar .
4. Ayrıca, ticari Health IT yazılımı geliştiriyorsanız, bir tıbbi cihaz veri sistemi (MDDS) oluşturup oluşturmadığınızı kendinize sormalısınız: Ürünüm bir MDDS mi?

Kısa cevap "Evet". Daha uzun ama daha doğru bir cevap "Ciddiye alırsanız."

(A) hasta güvenliği ve ürün kalitesi ve (b) endüstri düzenlemesi ile ilgili endişelere ayırmayı sevdiğim birkaç akılda tutulması gereken temalar var.

Güvenlik ve kalite tarafında, güvenli yazılım yapmanın zor olduğunu unutmayın. Bazı etki alanı bilgisine sahip birkaç iyi programcı oldukça güvenli olan inanılmaz kullanışlı yazılımları ortaya çıkarabilir. Yerel bir klinik ortamda dağıtımın bir parçasıysa ve yazılımın dağıtılması ve kullanılması sırasında olaylara yanıt vermeye ve ayarlamaya devam edebiliyorsa, yazılım hataları kullanmakla ilgili sadece birkaç yaralanma veya ölümle ilgili olarak değer sağlayabilir, tasarruf edebilir veya iyileştirebilir veya yazılım hataları. Ancak yazılım, programcıların yazılımın kullanımı geliştikçe yazılımı birlikte geliştirerek, her zaman orada olmalarını gerektirir. Bu ölçeklenebilir bir işlem değildir ve programcılar öldüğünde veya sıkıldığında sistem kolayca çok hızlı bir şekilde çok tehlikeli olabilir. Bu sonuçları iyileştirmek ve güvenli yazılım yapmak için, Yazılım geliştirilirken atılması gereken önemli geliştirme süreci adımları vardır. Bunlara iyi bir "kutudan çıkmayan" giriş, ISO / IEC 62304 tıbbi cihaz yazılımının geliştirilmesinde uluslararası standartlarda bulunabilir. Ana konsept, her aşamada emniyet riski yönetimidir - kullanım durumu analizi ve hikaye gelişimi, gereksinimler sırasında açıklama, sistem ve mimari tasarım, uygulama, birim ve entegrasyon testleri. Çevik olmak, bu çalışmaların hiçbirini ortadan kaldırmayacak ya da daha az zorlaştıracak, ancak değer yaratmayan ve değer yaratmayan (gereksiz özellikler veya aşırı doğrulama testi / düzeltme döngüleri gibi) çalışmayı ortadan kaldırarak çevik gelişim, Bir ekibin bu çalışmayı geliştirmeye entegre etmesine izin vererek aynı zamanda daha güvenli bir yazılım geliştirilmesini sağlayın. Çevik ekipler tarafından yaygın olarak kullanılan yinelemeli geliştirme uygulamaları, projenin hayatı boyunca gelişen ve sonrasında düşünülmüş olmak yerine, güvenlik riski yönetimi işini yapmak için çok uygundur. Yazılımın işletime alınmasından sonra, kullanıcılardan ve yaralanmaya neden olabilecek tüm potansiyel olaylardan, yazılımı güvenli bir şekilde kullanabilmek için bireysel olarak ve toplu olarak dikkate alınması gerekir. Agile, sistemin diğer bölümlerini parçalamadan değişiklikleri dahil etmek için hızlı ve güvenli bir süreç sağladığında burada yardımcı olabilir - bu da bir kez daha, yazılım geliştirildiğinde oluşturulan iyi bir mimari ve iyi anlaşılmış tasarım etkileşimleri gerektirir. projenin hayatı boyunca gelişen, sonradan görülen bir düşünce değil. Yazılımın işletime alınmasından sonra, kullanıcılardan ve yaralanmaya neden olabilecek tüm potansiyel olaylardan, yazılımı güvenli bir şekilde kullanabilmek için bireysel olarak ve toplu olarak dikkate alınması gerekir. Agile, sistemin diğer bölümlerini parçalamadan değişiklikleri dahil etmek için hızlı ve güvenli bir süreç sağladığında burada yardımcı olabilir - bu da bir kez daha, yazılım geliştirildiğinde oluşturulan iyi bir mimari ve iyi anlaşılmış tasarım etkileşimleri gerektirir. projenin hayatı boyunca gelişen, sonradan görülen bir düşünce değil. Yazılımın işletime alınmasından sonra, kullanıcılardan ve yaralanmaya neden olabilecek tüm potansiyel olaylardan, yazılımı güvenli bir şekilde kullanabilmek için bireysel olarak ve toplu olarak dikkate alınması gerekir. Agile, sistemin diğer bölümlerini parçalamadan değişiklikleri dahil etmek için hızlı ve güvenli bir süreç sağladığında burada yardımcı olabilir - bu da bir kez daha, yazılım geliştirildiğinde oluşturulan iyi bir mimari ve iyi anlaşılmış tasarım etkileşimleri gerektirir.

İkinci endişe düzenleyicidir. İdeal bir dünyada, güvenlik düzenlemeleri yeterince tehlikeli olabilecek tüm ürünlere uygulanacak ve bir satıcı çizgiyi geçmeye başladıktan sonra bazı basit şeyleri yerine getirerek uyabilecek. Uygulamada, küresel düzenlemeler bu sektörde karmaşık ve hızlı hareket etmektedir; bu, bir gün bazı tıbbi verileri gösteren küçük bir iPhone uygulaması geliştirebileceğiniz ve bir sonraki adımda “kalite yönetimi için ISO ve FDA standartlarına uymanız bekleneceği anlamına gelir. sistem "veya QMS. Geçmişte resmi bir KYS sahibi olmayan şirketler için bu korkutucu olabilir. Ve çevik bunu daha da şiddetlendirebilir çünkü bir ürün konseptiyle başlayabilirsiniz ve evrimsel gelişim yoluyla istemeden düzenlenmiş bir amaçlanan kullanıma (örneğin bir kullanıcıya klinik teşhis verilerini görüntülemek gibi) girebilirsiniz. Ekim 2011; Kategori adına "sağlık", "tıbbi", "sağlık hizmeti" olan bir ürünü pazarlamayı düşünen herhangi bir şirkete tavsiyem, yaptıkları ürünün dünyadaki bir veya daha fazla tıbbi cihaz düzenleyicisi tarafından ne zaman düzenleneceği konusunda bir plan yapmaları gerektiğidir. Burada yine çevik, yardımcı olabilir; çünkü çevik uygulamalar genel olarak hem piyasa öncesi giriş (FDA 510k gibi), hem de sertifikasyon (ISO 13485 gibi) ve pazar sonrası operasyonlar için düzenleyici müşterileri memnun etmek için uyumlu çıktılar üretir (veya kolayca üretebilir). İlk test geliştirme, tıbbi yazılımlara tam olarak uyar. Sürekli entegrasyon, otomatik birim testi ve SCRUM sprint meta verileri, risk yönetimi ve doğru doğrulama işlemlerinin yalnızca bir sonraki düşünce olarak değil, geliştirme sürecine dahil edildiğine dair eksiksiz bir kanıt sağlayabilir. Çoğu durumda çevikliğin, belki aynı biçimde değil, "şelale" den daha fazla eser ürettiğini düşünüyorum. Ancak çıktıların düzenleyicileri tatmin eden bir şeye dönüştürmesi çözülmesi nispeten küçük bir sorundur.

Yani özet olarak ... evet Virginia, sağlık bilişim teknolojileri (ve diğer tıbbi cihazlar) yazılım geliştirme için çevik. Her şey çevik olduğu gibi, işleme, iş desteğine ve cesarete kendini adamıştır.

Evet, çevik kalkınmanın öncüllerinden biri müşteri katılımıdır. Bu sağlık bilişim sistemleri ve işlemlerinde kritik öneme sahiptir. Bir müşteri temsilcisinin katılımı ve sağlık kararlarının hasta bakımını nasıl etkileyeceği konusunda girdi verilmesi durumunda, Sağlık Bilgi İşlem Departmanları daha iyi kararlar alacaktır.

Bunun mümkün olduğunu düşünüyorum, ancak sektörün çok büyük bir paradigma değişimine ihtiyacı var. İkinci yıl sağlık geliştiricisi olarak yaşıyorum ve güven ve kişisel organizasyon hiçbir yerde görünmüyor. Sağlık hizmetleri resmen çevik olarak benimsemekten büyük ölçüde faydalanacaktır, çünkü çoğunlukla yine de kaos, "thrash" denilen yinelemeli gelişim ve geç değişen gereklilikler nedeniyle, çünkü, büyük tasarım önlerinde hiçbir şey işe yaramıyor.

Sorunu anlıyorum. Çevik gelişimin güzel bir örneği biri için bir web sitesi oluşturmaktır. Genellikle bir müşteri tam olarak ne istediğini bilmez, bu yüzden müşteri ile çok fazla etkileşim var.

Sağlık BT bilgisayar bilimlerinde çok önceden tanımlanmış bir alan gibi görünebilir; katı standartlarla (DICOM, HL7), onları uygulamanın tek bir yolu var gibi gözüküyor, fakat aynı zamanda pek çok tercih ve karar verme var.

Bana göre, hangi ürünü yaparsanız yapın, önceden TÜM gereklilikleri belirleyemezsiniz , bu nedenle çevik bir yazılım geliştirme yöntemi çok iyi çalışır.

Belirtildiği gibi, cevap evet.

Düzenli veya yüksek riskli alanlara Çevik uygulanırken, her bir yinelemede "Tamamlandı" yı tanımlayarak yasal düzenlemelere uyum ve diğer risk azaltma stratejilerinin dahil edilmesini tanımlamanız gerekir. Örneğin, bu, her yinelemede QA dokümantasyonu, gereksinim izlenebilirliği, güvenlik denetimi ve diğer işlemlerin tamamlanmasını gerektirebilir.

Örneğin çevik yaklaşımların FDA tarafından düzenlenmiş ortamlara uygulanması için iyi sanat ve pratik var.

Kısa cevap: Evet. Agile hakkında Yüksek Güvence Ortamlarında bazı ipuçları veren iyi bir blog var.

Ancak yapılması gereken bazı tavizler var. Çevik Manifestoyu düşünün :

Bireyler ve süreçler ve araçlar üzerindeki etkileşimler

Kapsamlı dokümantasyon üzerinde çalışan yazılım

Sözleşme müzakere konusunda müşteri işbirliği

Bir planı takip ederek değişime cevap vermek

Düzenleyici kurumlar sol tarafa çevik ekiplerin yaptığı kadar değer verir, ancak sağ tarafta tipik bir çevik ekibin yapabileceğinden daha fazla vurgu gerektirir. Örneğin FDA, süreçlerinizi ve araçlarınızı doğrulamanızı gerektirir, oldukça kapsamlı tasarım ve test dokümantasyonu ister ve kesinlikle iyi bir planlama gerektirir.

Kapak tarafında, aşağıdakiler de dahil olmak üzere birçok çevik prensip sağlık dünyasına çok iyi uyuyor:

• TDD ve Çift Programlama - kaliteyi arttırın
• Sıkı Müşteri Geri Bildirim Döngüsü - erken doğrulama harika
• İteratif Planlama - düzenleyici kurumların tümü planlama ile ilgilidir

Bazı disiplinler doğada zaten çeviktir. Örneğin, hemşirelik, aşamalı olarak nihai sonuçlara ulaşmak için çoklu tanı / prognoz yinelemelerine dayanan bir 'değerlendirme-değerlendirme-planlama-müdahale' döngüsüne dayanır.

Bununla birlikte, bu şekilde sağlanan sağlık hizmetlerinin, söz konusu hizmet sunumunda kullanım için bir yazılım aracına veya sisteme yönelik esasen tek örnek bir Çevik yazılım geliştirme uygulamasına uygun olduğunu önermek, ölümcül bir konfederasyon olacaktır.

AAMI , AAMI TIR SW1, Çevik uygulamaların tıbbi cihaz yazılımının geliştirilmesinde kullanımı konusunda rehberlik eden bir Teknik Bilgi Raporu üzerinde aktif olarak çalışmaktadır
.

2012'de yayınlanabileceğini duydum.

Çevik Manifesto ilkelerinin (bkz. EpiGrads'ın cevabını) yasal düzenleme gereklilikleri, tipik süreçler ve tıbbi cihaz yazılımıyla ilgili diğer ürün pratikleriyle uyumlaştırılmasından bahseder.