Benim babam bir doktor. Programlama geçmişi olmayan kritik olmayan hasta bilgilerini saklamak için bir veritabanı yazmakta ısrar ediyor [kapalı]

Yani, babam şu anda küçük (4 doktor) uygulaması için GUI tabanlı bir veri tabanı aracı FileMaker Pro'yu kullanarak bir veritabanını "hackleme" sürecindedir. Veritabanı, tıbbi makinelerden raporlama üzerindeki yükü hafifletmek ve oldukça beceriksiz bir süreci kolaylaştırmak için kullanılacaktır.

Programlama geçmişi yok ve bir şeyler doğru öğrenmemek için elinden gelen her şeyi yapıyor gibi görünüyor. Yinelenen veri türleri, veritabanı tarafından zorlanan ilişkileri (yabancı / birincil anahtar kısıtlamaları) ve bir düzine başka sorunu var. Her şeyi Youtube videolarını kullanarak GUI aracıyla elle yapıyor.

Benim sorunum,% 100 başarılı olmasını isterken, bu tür kararları almasının uygun olduğunu düşünmüyorum. Bu konularda bir tür eğitim olmadan, birlikte saldırıya uğramış bir çözümün kötü bir fikir olduğuna nasıl ikna edebilirim? Oldukça inatçı olabilir ve bence bu tür işleri "çocuk oyunu" olarak görüyor

Buna nasıl yaklaşmalıyım? Bu kötü bir fikir bile mi - yoksa bunu idare etmek için uygun bir DBA / geliştirici tutması gerektiğini düşünüyor muyum?

Not: 4 yıllık bir geliştirici danışmanıyım ve ağrılı müşteri uygulamalarındaki payımı gördüm.

Güncelleme:

Şimdi birkaç yıl sonra ve bu soruyu düşünmek için zamanım vardı. Babam, Google Dokümanlar, FileMaker Pro ve bazı e-posta kancalarını kullanarak bir çözüm uyguladı. Her şeyi kendisi kurdu ve ondan çok büyük bir değer elde ettiğini söylüyor.

Deneyimli bir geliştiriciyseniz, belki de bu tanımı okuyup okuyorsunuz. Ama aslında her şeyden oldukça iyi bir ders aldım - insanların sadece sonuçları değil, uygulamayı önemsediğini. Babamın umurunda olduğu tek şey, hasta bilgilerini kağıda manuel olarak girmesi gerekmemesidir ve bunun yerine bir Google doküman formunu hızla doldurabilir. Harika olan, sadece kendi uygulamalarındaki otomasyona odaklanmak için bir genç dev / ops kişisini işe almasıdır.

Uzun yıllardır Sağlık çözümleri üretiyorum. Babanın bunu yapmaması gereken tüm farklı nedenlere girmeyeceğim; akademik nedenlerin çoğu: yani, eğer yeterince sektördeyseniz, bu şeylerin nasıl kartopu yaptığını ve kendi hayatlarını nasıl geliştirdiklerini bilirsiniz.

Bunun yerine, bir doktor olarak, babanızın profesyonel nedenleri ve gerçek hayattan, akademik olmayan, yaptığı şeyin tehlikeli ve muhtemelen hayatı tehdit eden nedenlerini anlaması gerekir; meslektaşları için tehlikeli, hastalarının mahremiyeti ve kimliği için tehlikeli ve hukuki açıdan uygulamaları için tehlikeli.

Tehlike çok yönlüdür:

1. hasta mahremiyeti (HIPAA, ARRA, Anlamlı Kullanım, HITECH Uyumluluğu)
   • hasta tanımlama alanları olarak kabul edilen alanlar nelerdir (sektördeki birçok profesyonel bunu anlamamaktadır ve sadece soyadı, adres, posta kodu gibi bariz alanlardan bazılarını ortadan kaldırdığınız için bunu yapacak birçok alan vardır. klinik verileri belirli bir hastayla ilişkilendirmek kolaydır; bu kendi başına zordur; klinik verileri tanımlayan çok para kazanan şirketler var - bu kendi başına bir alan.
2. HIPAA, HITECH ve daha yeni mevzuat,
   • denetim yapılmalıdır
   • güvenlik yapılmalıdır
   • parola gereksinimleri
   • kalan veriler şifrelenmeli mi
   • iletilen veriler şifrelenmeli ve nasıl
   • herhangi bir barındırılan hizmet (IaaS, PaaS) kullanıyorsanız denetimleri göz önünde bulundurmalısınız
   • yerinde uygun BAA ve DSA var mı
   • sunucularınızı barındıranlar erişimi nasıl kontrol eder?
   • çoklu kiracılığı nasıl ele alıyorlar (bu büyük varlıkların bazılarının bunu uygun şekilde nasıl halletmediğine şaşıracaksınız)
   • altyapınızı barındıranlarla sözleşmeyi feshederseniz, verilerinizin kalıcı olarak silinmesini nasıl sağlayacaklardır (NIST düzenlemeleri)
3. gelişiminiz için geçerli kontroller nelerdir
   • yerinde bir sdlc var mı
   • gereksinimlerden koda, KG'ye kadar izlenebilirliğiniz var mı
   • tıbbi uygulamanızın / cihazınızın 'amaçlanan' kullanımını doğrulıyor musunuz?
4. yazılımınız QA'd mı ve bir Kullanıcı Kabul Testi (UAT) ortamınız var mı?
   • bu ortamı nasıl korursunuz, çünkü gerçek hasta verilerini kullanacaksınız
5. Medicare hastalarını idare edecek mi, eğer öyleyse veritabanını rapor etmek için kullanmayı planlıyor mu?
   • hükümetin bu verilerin Sağlık Bilgi Alışverişine (HIE) değişimi için sıkı kontrolleri vardır
   • klinik veri havuzundan (CDR) yararlanmak istiyorsa kendi değişimini nasıl uygulayacağına
6. veri güvenliği için uyması gereken belirli NIST düzenlemelerini anlıyor mu?
   • verilerin kalıcı olarak silinmesi gibi (barındırılan bir altyapı kullanılıyorsa)
7. tıbbi makinelerden veri alacağını söylemiştin
   • yeni FDA tıbbi cihaz standartlarını anlıyor mu?
   • 2013'ten başlayarak, tıbbi cihazlardan veri görüntüleyen herhangi bir dijital sistem tıbbi bir cihaz olarak kategorize edilebilir ... Bu, tıbbi cihazlar için FDA düzenleme gereksinimlerini karşılaması gerektiği anlamına gelir.
8. ekibi ve personeli veritabanındaki verilere dayanarak tıbbi kararlar alacak mı?
   • sürekli değişen gereksinimleri karşılayacak kadar esnek olan sağlam bir klinik veri modeli geliştirdi mi (örneğin, ICD-9 ila ICD-10 ila ICD-11 kodlama standartları)?
   • veri modelini nasıl sürümlendirecek ve verilerle senkronize tutacaktır (yani, klinik veri modelini değiştirirse eski veriler nasıl temsil edilir?)
   • sistemi, klinik kararın verildiği gün görüldüğü gibi klinik verilerin kesin bir görüntüsünü üretebilecek mi? yapamazsa yasal yankılar var
   • gerçek bir silme ile mantıksal silme arasındaki farkı ve veri modeline etkilerini biliyor mu; depolama gereksinimlerine; uygulama politikalarına göre?
   • kullanması gereken tüm farklı hizmetleri yönetmek için bir kelime dağarcığı çözümü var mı; verilerin çoğunun kodlanması gerekir (serbest metnin aksine), çünkü ICD-9 uyumlu raporlar üretmek için CDR'sinden yararlanmak isteyecektir. Ve sonra bu standartların değişmesini hesaba katması gerekiyor; örneğin, ICD-9 ila ICD-10.
   • kelime dağarcığı, terminoloji veya Sağlık Veri Sözlüğü (temelde eşanlamlı kelimeler) için eski terminolojinin eski klinik kararlar için hala verilebilmesini nasıl sağlayacak ve sağlayacak?
9. alerji verilerini depolayacak mı?
   • 'tıbbi terminoloji' veya 'kelime hazinesi' tanımları nasıl saklanacak?
   • LOINC ve First Data Bank gibi diğer terminoloji sistemleriyle entegre olacak mı?
   • terminoloji hizmetleri (Sağlık Veri Sözlüğü)
10. Verileri kendi sistemiyle ve belki de bir sağlık bilgi alışverişine (HIE) arayüzle bağlamak isteyecek mi?
    • eğer öyleyse, HL7 ve onun veritabanı üzerindeki etkisini anlıyor mu?
    • arayüz motorlarını ve bununla birlikte giden her şeyi anlıyor mu?
11. bilginin nasıl tanımlanacağını anlıyor mu?
    • bu geliştirme aşamasında ve hata düzeltme aşamasında önemlidir

Bunlar sadece birkaç soru ve hiçbir şekilde kapsamlı bir liste olarak düşünülmemelidir. Ve her cevap için sayısız soru olacak.

Bir Sağlık Veritabanında, önceki verilerin silinmesi veya üzerine yazılması olmamalıdır. Bu, asla 'yerden sil ...' veya 'güncelleme ayarlandı ...' olmayacağı anlamına gelir. Bunun yerine yalnızca kesici uçlarınız olacaktır. Bunun veri modelinizi ve sorgularınızı nasıl değiştirdiğini hayal edebilirsiniz. Artık yaratıcı olabilir ve bu hedefe ulaşmak için farklı çözümler üretebilirsiniz, ancak gerçek şu ki bu Sağlık Klinik Veri havuzuna özgü bir gereksinimdir.

Bu sorunun yaşamı tehdit eden tarafı hakkında sadece bir düşünce daha vardı:

Örneğin, alerji bilgilerini alalım; Bunu yükseltiyorum, çünkü bunu yıllardır dijital olarak yapan kurumlar, süreçlerinin alerji verilerinin yakalanmasını sağlaması gerektiğini ve teknoloji bir veritabanındaki verileri yakaladığı için bir şekilde sonsuza kadar doğru olduğunu kabul edemeyeceğimizi öğrendi. . Bu nedenle hastalardan, aynı hastanede bile bir bölümden diğerine geçerken her seferinde alerjileri istenir. Bir hastanın alerjileri silinemez (bir satırdaki güncellemeler eski bilgileri siler). Dijital verilere dayanan bir klinik kararın, karar anında klinisyene 'sunulan' durumu yakalaması gerekir.

Bunun çoğunun büyük bir kuruma yönelik olabileceğini biliyorum. Ancak, düzenleyici kısımlar değildir. Ve her durumda, Sağlık Bilgi Sistemleri doğası gereği karmaşıktır. Sağlık sistemi mühendisliği, iyi klinisyenlerin uzmanlıklarına ve deneyimlerine bağlıdır. Ancak, Sağlık BT alanında ortalama bir empedans uyumsuzluğu (ORM teknolojisinden terminoloji ödünç almak için) daha büyük ... Her alanın uyumsuzluğu olduğu için daha büyük demeye çalışıyorum.

İyi şanslar!

Saldırıya uğramış bir çözüm her zaman kötü değildir. Eğer onun problemini çözerse, onun üzerine çok fazla pis kokmazdım. Her profesyonel veritabanı çözümü için Dosya Oluşturucusu ve Access'te muhtemelen birlikte çalışan 10 çözüm var. Sonuçta, Filemaker ve Access bunun için. Elbette, saldırıya uğramış çözümlerin çoğu kaputun altında korkunç. Ancak güzellik yarışmaları kazanmak için değil, sorunları çözmek için varlar. Genellikle bu çözümlerin kapsamı büyür ve o zaman birisi profesyonel bir çözüm oluşturmak için işe alınır.

Başarı şansına yardımcı olmak için yapabileceğiniz şey, projesine olan ilgisini açıklamak ve oturup veritabanını tanımlamasına ve her şeyi gözden geçirmesine yardımcı olmaktır. Eğer yardımını istemiyorsa ... bırak ve bırak. Ne yapacaksın baban porsuk? Başının üstüne girerse / girerse size haber verir.

Dikkate alınması gereken başka bir şey, bunun doktorlar arasında ortak bir sorun olması durumunda, genel bir çözüm yaratmada çok iyi bir iş fırsatınız olabilir.

25 yılı aşkın deneyime sahip bir yazılım tasarımcısı olarak, yine de bir şeyi kendiniz hazırlamanın cazibesini görebiliyorum. Bu sektörde tecrübeli olmayan birine bir şeyler açıklamak büyük bir sürükleme olabilir.

Peki, veritabanı normalleştirilmezse veya daha hızlı hale getirilebilirse ne olur? Birçok kritik olmayan yazılım (özellikle çevik çağda) wabi-sabi ilkesini izler. Yapması gerekeni yapar ve artık yapmaz.

Tüm yazılımların mükemmel bir arayüz, yıldırım hızında veritabanı erişimi ve kusursuz bir GUI ile birlikte çığlık atması gerekmediğini lütfen unutmayın.

Benim sorunum,% 100 başarılı olmasını isterken, bu tür kararları almasının uygun olduğunu düşünmüyorum.

Filemaker, herkesin kullanabileceği bir veritabanı olarak başladı ve bu rolde hala çok iyi çalışıyor. Babanız ne istediğini biliyorsa ve onu bir araya getirirken rahat hissediyorsa, ne hakkında endişeleniyorsunuz? İstediği gibi çalışırsa kazanır. Eğer istediği gibi çalışmazsa, düzeltir.

Kaiser Permanente için çalışan tüm doktorlar için bir veritabanı oluşturuyorsa endişelenmeye hak kazanırsınız, ancak sadece kendi pratiğinde kullanmak için bir araç oluşturuyorsa, muhtemelen bunları idare etmek için tam olarak doğru kişi gibi görünüyor. kararlar.

Mükemmelin iyinin düşmanı olmasına izin vermeyin.

Benim tavsiyem bu yokmuş gibi davranmak yoksa yoksa seni çıldırtır. Müşteri listesiyle benzer bir şey yapan bir akrabam var ve kendi başına yarattığı şey bir canavarlık. Başlangıçta yardım teklif etti ve o (ki bir "aile" indirim vardı) benim teklif çirkin olduğunu düşündüm. Bir göz attıktan sonra bir kaç değişiklik önerdim ve benden "birkaç bira" karşılığında yapmamı istedi. Aile ya da değil, Homie bunu oynamıyor. Ona bunu yapmak için birini işe alması gerektiğini söyledim, ama asla yapmadı. Sadece projenin berbatlığını bana yemekten alıkoymak için kendimi tamamen kestim ve yokmuş gibi davrandım.

Denemesine izin vermelisin. Bununla birlikte, onu bir çıkmaza ulaştığında, onun sorunu ve o noktada işe almaya karar verdiği herhangi bir geliştiricinin sıfırdan başlaması gerektiğinin farkında olmalısınız.

Mobilya ve hatta sıhhi tesisat gibi şeyleri birlikte kesmek isterim. Zevk alıyorum ve yanlış bir şey görmüyorum. Asla sıkışıp kaldığımda yetenekli bir ustadan benim için atlamasını istemeye cesaret edemem, çünkü sadece kreasyonlarımın sadece görüşüne kusacaklarını düşünüyorum.

Öyleyse baban istediği şeyi yapsın ama riskleri anlamasına izin ver. Sadece ona, bir noktada eğitimli bir geliştiriciyi "sadece küçük bir özellik eklemek" için işe aldığında, deneyimli ustalardan en fazla kablolama ve tesisatın yapıldığı bir evde "sadece birkaç şeyi düzeltmesini" istemek gibi olduğunu açıklayın. koli bandı, alüminyum folyo, Hamuru ve iyi niyetle.

bu tür işleri "çocuk oyunu" olarak görür

4 yıllık geliştirici danışmanıyım

Kendi iyiliğiniz ve babanızın kişisel gelişimi için başarısız olmasına izin verin. John'un cevabı çok sağlamdır ve babanızın yasanın yanlış tarafına girmesini engelleyecek kadar ya da en azından daha iyi bilmesi için yeterince bahsetmelisiniz. Ama bütün bu "alçakgönüllülük" şey insanlara ders verebileceğiniz ve öğrenmelerini bekleyebileceğiniz bir şey değildir. En zor ve tamamen başarısız olmak için çok önemli bir yaşam dersi. Başarısızlık çok güçlü bir öğretmendir. Ve oğlunun mesleğine biraz saygı duyabilir.

Ve hey, yeterince iyi çalışan (ve herhangi bir yasayı ihlal etmeyen) bir şeyi kaldırmayı başarırsa, ona daha fazla güç.

Bu onun işi. Ve eğer kararlıysa, çalışmasını sağlar. Ve pek çok kişi işlerin çalışmasını sağlamak için çeşitli teknolojilerden çözümler bir araya getirdiler.

Yıllar önce, bir web uygulamasını PHP ve bazı bülten tahtası yazılımlarıyla bir araya getiren bir arkadaşımın kodunu inceledim. İhtiyaçlarını karşılamak için yoğun şekilde özelleştirdi. Kod iğrençti. Sadece normal formun dışında, veritabanında veri bulunan HTML etiketleri vardı. MVC ayrımı yok. Ama Tanrı onu kutsasın. Başvurusu işe yaradı ve faturalarını bu web sitesinden elde edilen gelirle ödeyebildi.

Ona tavsiyem şuydu: Başvurunuzu mümkün olduğunca uzun süre süt sağmaktan memnunsanız, iyi yazılım tasarım teknikleri kullanarak yeniden düzenleme yapmayın ve "yeterince iyi" bırakın. Uygulamanızı daha fazla hizmet sunmak ve daha fazla gelir elde etmek için geliştirmek istiyorsanız, kodu ödemeniz ve yeniden düzenlemeniz gerekir. Birincisiyle gitmeyi seçti. En la vie.

Babanız şimdi veri çoğaltma ve zayıf veri bütünlüğünün acısını hissetmiyorsa, daha sonra olacak ve ancak o zaman söylediklerinizin değerini öğrenecek.

Sorunuzun cevabının esas olarak tıbbi uygulaması için ne kadar kritik olduğuna bağlı olduğunu düşünüyorum. Sadece yararlı bulduğu bazı hasta verilerini depolayacak mı yoksa bu uygulamanın herhangi bir arızasının ciddi sonuçları olabilir mi? Eğer ciddi sonuçları olabilirse, bunu yapmamalı ama onu iyi bir fikir olmadığına ikna eden mükemmel bir dünyada yaşamadığımız için tamamen farklı bir konu olabilir.

Bir geliştirici danışmanı olduğunuz için ona KG ve test sürecinde yardım teklif etmenizi öneririm. Bu şekilde babanla iyi bir ilişki kuracaksın çünkü ona "yardım ediyorsun" ama aynı zamanda uygulamasının yapması gerekeni yaptığını ya da çözemeyeceği bir problem bulacağından emin olabilirsin. böylece daha profesyonel bir çözüm arayacak.

BTW İşlerini yapan çok sayıda korkunç uygulama gördüm ve bunun neden korkunç olduğunu kimsenin gerçek değişiklikler yapmaya ikna edeceğini açıklamam.

Kar amacı gütmeyen büyük bir sağlık hizmeti sağlayıcısı için yakın zamanda emekli bir yazılım mühendisi olarak, makul bir ücret karşılığında, Anlamlı Kullanım girişimi gereksinimlerini karşılayan elektronik tıbbi kayıt sistemlerini paylaşmasına izin verebilecek bir hastane veya büyük bir uygulama aramanızı şiddetle tavsiye ediyorum. (ve diğer hükümet teşvik programları).

“Epic” in ( http://Epic.com ) daha küçük sağlayıcıların sistemlerini paylaşmasına olanak tanıyan müşterilerini desteklediğinin farkındayım ve bazı rakiplerinin de yaptığını hayal ediyorum. Cerner onların en büyük rakibi, ama diğerleri tartışılıyor http://www.beckershospitalreview.com/healthcare-information-technology/50-things-to-know-about-epic-cerner-meditech-mckesson-athenahealth-and- diğer-majör-ehr-vendors.html

Bu tür paylaşımlar için CMS'den% 75 sübvansiyon vardır. Abonelik fiyatını maliyetimizin% 25'ini yaparak müşterilerimize sübvansiyon verdik.