Ayahku adalah seorang dokter. Dia bersikeras menulis database untuk menyimpan informasi pasien yang tidak kritis, tanpa latar belakang pemrograman [ditutup]

Jadi, ayah saya saat ini sedang dalam proses "meretas" sebuah basis data menggunakan FileMaker Pro, alat basis data berbasis GUI untuk praktik kecilnya (4 dokter). Basis data akan digunakan untuk membantu meringankan beban pelaporan dari mesin medis, merampingkan proses yang cukup canggung.

Dia tidak memiliki latar belakang pemrograman, dan tampaknya melakukan segala daya untuk tidak mempelajari hal-hal dengan benar. Dia punya tipe data duplikat, tidak ada hubungan yang ditegakkan dengan basis data (batasan kunci asing / primer) dan selusin masalah lainnya. Dia melakukan semuanya dengan tangan melalui alat GUI menggunakan video Youtube.

Masalah saya adalah, bahwa sementara saya ingin dia berhasil 100%, saya pikir tidak pantas baginya untuk menangani keputusan seperti ini. Bagaimana saya meyakinkannya bahwa tanpa semacam pendidikan dalam topik ini, solusi yang diretas bersama adalah ide yang buruk? Dia bisa sangat keras kepala dan saya pikir dia melihat jenis pekerjaan ini sebagai "permainan anak-anak"

Bagaimana saya harus mendekati ini? Apakah itu ide yang buruk - atau apakah saya benar dalam berpikir ia harus menyewa DBA / pengembang yang tepat untuk menangani ini sehingga tidak menjadi mimpi buruk pemeliharaan?

NB: Saya seorang konsultan pengembang selama 4 tahun dan saya telah melihat bagian saya dari implementasi pelanggan yang menyakitkan.

Memperbarui:

Jadi beberapa tahun kemudian sekarang, dan saya punya waktu untuk merenungkan pertanyaan ini. Ayah saya akhirnya menerapkan solusi menggunakan Google Docs, FileMaker Pro dan beberapa kait email. Dia mengatur semuanya sendiri, dan dia bilang dia mendapatkan nilai yang sangat besar darinya.

Jika Anda adalah pengembang yang berpengalaman, Anda mungkin membaca deskripsi dan ngeri itu. Tapi sebenarnya saya belajar pelajaran yang cukup bagus dari semuanya - bahwa orang hanya peduli dengan hasilnya, dan bukan implementasinya. Yang ayah saya pedulikan adalah kenyataan bahwa dia tidak perlu memasukkan informasi pasien di atas kertas secara manual, dan sebagai gantinya dapat dengan cepat mengisi formulir Google docs. Apa yang hebat adalah dia mencari untuk mempekerjakan orang junior dev / ops untuk fokus hanya pada otomatisasi dalam praktiknya.

Saya telah merancang solusi Kesehatan selama bertahun-tahun. Saya tidak akan membahas semua alasan yang berbeda bahwa ayah Anda seharusnya tidak melakukan ini; sebagian besar alasan menjadi akademis: artinya, jika Anda sudah berkecimpung dalam industri ini cukup lama, Anda tahu bagaimana hal-hal ini berubah dan mengembangkan kehidupan mereka sendiri.

Sebaliknya ayahmu, sebagai dokter, perlu memahami alasan profesional dan kehidupan nyata, non-akademik, alasan mengapa apa yang dia lakukan berbahaya dan mungkin mengancam jiwa; berbahaya bagi rekan-rekannya, berbahaya bagi privasi dan identitas pasiennya, dan berbahaya bagi praktiknya dari sudut pandang hukum.

Bahayanya multi-segi:

1. privasi pasien (HIPAA, ARRA, Penggunaan Bermakna, Kepatuhan HITECH)
   • apa bidang yang dianggap bidang pengidentifikasian pasien (banyak profesional di industri tidak memahami ini, dan hanya karena Anda menghilangkan beberapa bidang yang jelas seperti nama belakang, alamat, kode pos, masih ada banyak bidang lain yang akan membuatnya mudah untuk mengaitkan data klinis ke pasien tertentu; ini, dengan sendirinya, sulit; ada perusahaan di luar sana menghasilkan banyak uang de-mengidentifikasi data klinis - itu adalah seluruh domain itu sendiri).
2. HIPAA, HITECH dan legislasi yang lebih baru menjelaskan dengan jelas caranya
   • audit harus dilakukan
   • keamanan harus dilakukan
   • persyaratan kata sandi
   • seandainya data yang dienkripsi dienkripsi
   • haruskah data yang dikirimkan dienkripsi, dan caranya
   • Anda harus mempertimbangkan kontrol jika Anda menggunakan segala jenis layanan yang di-host (IaaS, PaaS)
   • apakah Anda memiliki BAA dan DSA yang tepat di tempat
   • bagaimana mereka yang hosting server Anda mengontrol akses
   • bagaimana mereka menangani multi-tenancy (Anda akan kagum melihat bagaimana beberapa entitas besar ini TIDAK menangani ini dengan tepat)
   • jika Anda mengakhiri kontrak dengan mereka yang meng-hosting infrastruktur Anda, bagaimana mereka memastikan penghapusan permanen data Anda (peraturan NIST)
3. apa saja kontrol pemerintahan yang ada untuk pengembangan Anda
   • apakah Anda memiliki sdlc di tempatnya
   • apakah Anda memiliki keterlacakan dari persyaratan ke kode ke QA
   • apakah Anda memvalidasi penggunaan aplikasi / perangkat medis yang Anda maksudkan?
4. adalah perangkat lunak Anda sedang QA, dan apakah Anda memiliki lingkungan Tes Penerimaan Pengguna (UAT)
   • bagaimana Anda mengamankan lingkungan ini, karena Anda akan menggunakan data pasien sungguhan
5. apakah dia akan menangani pasien medis, jika demikian dia berencana menggunakan databasenya untuk melaporkan?
   • pemerintah memiliki kontrol ketat untuk pertukaran data ini dengan Health Information Exchange (HIE) mereka
   • yang mengarah ke bagaimana dia akan menerapkan pertukarannya sendiri jika dia ingin mengambil keuntungan dari penyimpanan data klinisnya (CDR)
6. apakah dia memahami peraturan NIST tertentu yang harus dia patuhi untuk keamanan data
   • seperti penghapusan data secara permanen (jika menggunakan infrastruktur yang dihosting)
7. Anda menyebutkan dia akan mengambil data dari mesin medis
   • apakah dia memahami standar perangkat medis FDA yang baru?
   • mulai tahun 2013, sistem digital apa pun yang menampilkan data dari perangkat medis dapat dikategorikan sebagai perangkat medis ... ini berarti ia harus memenuhi persyaratan peraturan FDA untuk perangkat medis
8. apakah tim dan stafnya akan membuat keputusan medis berdasarkan data dalam database-nya?
   • sudahkah dia mengembangkan model data klinis yang solid, cukup fleksibel untuk menangani persyaratan yang selalu berubah (yaitu, ICD-9 hingga ICD-10 hingga standar pengkodean ICD-11)?
   • bagaimana dia akan membuat versi model data dan tetap menyelaraskannya dengan data (yaitu, jika dia mengubah model data klinis bagaimana data yang lebih lama akan diwakili?)
   • Akankah sistemnya dapat menghasilkan snapshot yang tepat dari data klinis seperti yang terlihat pada hari keputusan klinis dibuat? ada akibat hukum jika dia tidak bisa
   • apakah dia tahu perbedaan antara penghapusan nyata dan penghapusan logis, dan implikasinya terhadap model datanya; untuk persyaratan penyimpanannya; untuk kebijakan praktiknya?
   • apakah dia memiliki solusi kosa kata untuk menangani semua layanan yang berbeda yang perlu dia gunakan; banyak data yang perlu dikodekan (bukan teks bebas), karena ia ingin memanfaatkan CDR-nya untuk menghasilkan laporan yang sesuai dengan ICD-9. Dan kemudian dia harus memperhitungkan perubahan standar-standar ini; misalnya, ICD-9 hingga ICD-10.
   • untuk kosa kata, terminologi atau Kamus Data Kesehatan (semua pada dasarnya sinonim) bagaimana ia akan menerapkan dan memastikan bahwa terminologi lama masih dapat diterjemahkan untuk keputusan klinis lama?
9. apakah dia akan menyimpan data alergi?
   • bagaimana definisi 'terminologi medis' atau 'kosakata' nya disimpan?
   • apakah dia akan berintegrasi dengan sistem terminologi lain seperti LOINC dan First Data Bank?
   • apakah dia memiliki pemahaman tentang layanan terminologi (mis. Kamus Data Kesehatan)
10. apakah dia ingin memiliki data yang dihubungkan ke sistemnya, dan mungkin ke pertukaran informasi kesehatan (HIE)?
    • jika demikian, apakah dia mengerti HL7 dan dampaknya pada database-nya?
    • apakah dia mengerti mesin antarmuka dan semua yang sejalan dengan itu?
11. apakah dia mengerti bagaimana cara menghilangkan informasi?
    • ini penting dalam fase pengembangan dan fase perbaikan bug

Ini hanya beberapa pertanyaan, dan sama sekali tidak harus dianggap sebagai daftar yang komprehensif. Dan untuk setiap jawaban akan ada lebih banyak pertanyaan lagi.

Dalam database Healthcare tidak boleh ada penghapusan atau penulisan data sebelumnya yang berlebihan. Ini berarti tidak akan pernah ada 'hapus dari mana ...' atau 'set pembaruan ...'. Sebaliknya Anda hanya akan memiliki sisipan. Anda dapat membayangkan bagaimana ini mengubah model data dan kueri Anda. Sekarang Anda bisa berkreasi dan menghasilkan solusi yang berbeda untuk mencapai tujuan ini, tetapi faktanya tetap bahwa ini adalah persyaratan yang unik untuk repositori Data Klinis Kesehatan.

Hanya satu pemikiran lagi tentang sisi yang mengancam jiwa dari masalah ini:

Mari kita ambil, misalnya, informasi alergi; Saya mengangkat ini karena lembaga yang telah melakukan ini secara digital selama bertahun-tahun telah belajar bahwa proses mereka perlu memastikan bahwa data alergi ditangkap dan bahwa kita tidak dapat berasumsi bahwa karena teknologi menangkap data dalam database itu entah bagaimana secara inheren mengoreksi selamanya . Inilah sebabnya mengapa pasien diminta alergi setiap kali ketika mereka berpindah dari satu departemen ke departemen lain, bahkan di dalam rumah sakit yang sama. Alergi pasien tidak dapat dihapus (pembaruan pada satu baris menghapus informasi lama). Keputusan klinis berdasarkan data digital perlu menangkap apa yang 'dipresentasikan' kepada klinisi pada saat pengambilan keputusan.

Saya tahu banyak dari ini yang tampaknya ditujukan untuk lembaga besar. Namun, bagian regulasi tidak. Dan bagaimanapun, Sistem Informasi Kesehatan pada dasarnya rumit. Rekayasa sistem kesehatan tergantung dan mengakui keahlian dan pengalaman dokter yang baik. Namun, ada ketidakcocokan impedansi lebih besar dari rata-rata (untuk meminjam terminologi dari teknologi ORM) dalam domain IT Healthcare ... Saya berani mengatakan lebih besar karena setiap domain memiliki ketidakcocokan.

Semoga berhasil!

Solusi yang diretas bersama tidak selalu buruk. Jika itu menyelesaikan masalahnya, aku tidak akan terlalu menyebalkan. Mungkin ada 10 solusi yang berhasil diretas bersama di File Maker dan Access untuk setiap solusi basis data profesional. Lagipula, itulah gunanya Filemaker dan Access. Tentu, sebagian besar solusi yang diretas bersama mengerikan di bawah tenda. Tapi mereka ada untuk menyelesaikan masalah, bukan memenangkan kontes kecantikan. Seringkali ruang lingkup solusi ini tumbuh, dan saat itulah seseorang disewa untuk membangun solusi profesional.

Apa yang mungkin Anda lakukan untuk membantu peluangnya untuk sukses adalah menyatakan minatnya dalam proyeknya dan menawarkan diri untuk duduk & membantunya menentukan basis data dan menelusuri semua hal. Jika dia tidak ingin bantuan Anda ... jatuhkan & biarkan saja. Apa yang akan kamu lakukan, musang ayahmu? Jika / ketika dia berada di atas kepalanya, dia akan memberi tahu Anda.

Hal lain yang perlu dipertimbangkan adalah jika ini adalah masalah umum di antara dokter, Anda mungkin memiliki peluang bisnis yang sangat baik dalam menciptakan solusi generik.

Sebagai seorang perancang perangkat lunak dengan 25+ tahun pengalaman, saya masih bisa melihat daya tarik dalam membuat sesuatu sendiri. Menjelaskan hal-hal kepada seseorang yang tidak berpengalaman dalam industri itu bisa menjadi hambatan besar.

Jadi bagaimana jika database tidak dinormalisasi atau bisa dibuat lebih cepat? Banyak perangkat lunak yang tidak kritis (terutama di zaman yang gesit) mengikuti prinsip wabi-sabi. Itu melakukan apa yang perlu dilakukan dan tidak lebih.

Harap menghargai bahwa tidak semua perangkat lunak harus berteriak bersama dengan antarmuka yang sempurna, akses basis data yang sangat cepat dan GUI yang sempurna.

Masalah saya adalah, bahwa sementara saya ingin dia berhasil 100%, saya pikir tidak pantas baginya untuk menangani keputusan seperti ini.

Filemaker memulai sebagai database yang dapat digunakan siapa saja, dan masih berfungsi dengan baik dalam peran itu. Jika ayahmu tahu apa yang dia inginkan dan merasa nyaman menggabungkannya sendiri, apa yang kamu khawatirkan? Jika berhasil seperti yang diinginkannya, dia menang. Jika itu tidak bekerja seperti yang dia inginkan, dia akan memperbaikinya.

Anda akan benar khawatir jika dia membangun database untuk semua dokter yang bekerja untuk Kaiser Permanente, tetapi jika dia hanya membangun alat untuk digunakan dalam praktiknya sendiri, sepertinya dia mungkin orang yang tepat untuk menangani ini. keputusan.

Jangan biarkan sempurna menjadi musuh kebaikan.

Saran saya adalah berpura-pura ini tidak ada atau tidak akan membuat Anda marah. Saya memiliki kerabat yang melakukan hal serupa dengan daftar kliennya, dan apa yang dia buat sendiri adalah sebuah keburukan. Saya awalnya menawarkan untuk membantu dan dia pikir kutipan saya (yang memiliki diskon "keluarga" lumayan) keterlaluan. Setelah memeriksanya, saya menyarankan banyak perubahan, yang dia minta saya buat sebagai ganti "beberapa gelas bir." Keluarga atau tidak, Homie tidak memainkannya. Saya mengatakan kepadanya bahwa dia harus mempekerjakan seseorang untuk melakukannya, tetapi dia tidak pernah melakukannya. Saya hanya harus memotong diri saya dari itu sepenuhnya dan berpura-pura itu tidak ada, hanya untuk menjaga mengerikannya proyek agar tidak memakan saya.

Anda harus membiarkannya mencoba. Namun, Anda harus membuatnya sadar akan fakta, bahwa ketika ia mencapai jalan buntu, itu masalahnya dan pengembang mana pun yang ia putuskan untuk merekrut pada saat itu, harus mulai dari awal.

Saya suka meretas banyak hal, seperti furnitur dan bahkan pipa ledeng. Saya menikmatinya dan saya tidak melihat ada yang salah dengan itu. Aku bahkan tidak pernah berani meminta pengrajin yang terampil untuk menerjangku ketika aku buntu, hanya karena aku pikir mereka akan muntah hanya dengan melihat kreasi saya.

Jadi biarkan ayahmu melakukan apa yang dia suka, tetapi cobalah untuk membiarkan dia memahami risikonya. Cukup jelaskan kepadanya, bahwa ketika dia pada suatu saat mempekerjakan pengembang terlatih untuk "hanya menambahkan satu fitur kecil", itu seperti meminta pengrajin berpengalaman untuk "hanya memperbaiki beberapa hal" di sebuah rumah di mana sebagian besar kabel dan pipa telah dilakukan dengan lakban, aluminium foil, plastisin dan itikad baik.

dia melihat jenis pekerjaan ini sebagai "permainan anak-anak"

Saya seorang konsultan pengembang selama 4 tahun

Demi kesejahteraan Anda sendiri dan perkembangan pribadi ayah Anda biarkan dia gagal. Jawaban John sangat kuat dan Anda harus menyebutkan cukup untuk menjaga ayah Anda dari sisi hukum yang salah, atau setidaknya cukup sehingga dia harus tahu lebih baik. Tetapi keseluruhan "kerendahan hati" ini bukanlah sesuatu yang dapat Anda ceramahi kepada orang-orang dan mengharapkan mereka untuk mempelajarinya. Ini adalah pelajaran hidup yang sangat penting untuk mencoba yang paling sulit dan gagal total. Kegagalan adalah guru yang sangat kuat. Dan dia mungkin mendapatkan respek terhadap profesi putranya.

Dan hei, jika dia berhasil merobohkan sesuatu yang berfungsi cukup baik (dan tidak melanggar hukum apa pun), semakin besar kekuatan baginya.

Ini urusannya. Dan jika dia bertekad, dia akan membuatnya bekerja. Dan banyak orang telah membuat solusi bersama dari berbagai teknologi untuk membuat pekerjaan berjalan lancar.

Bertahun-tahun yang lalu, saya meninjau kode seorang teman saya yang membuat aplikasi web dengan PHP dan beberapa perangkat lunak papan buletin. Dia menyesuaikannya dengan berat untuk memenuhi kebutuhannya. Kode itu adalah kekejian. Selain hampir tidak menjadi bentuk normal pertama, ia memiliki tag HTML dengan data di databasenya. Tidak ada pemisahan MVC. Tapi Tuhan memberkati dia. Permohonannya berhasil, dan ia dapat membayar tagihannya dengan penghasilan dari situs web itu.

Saran saya kepadanya adalah ini: Jika Anda puas dengan susu aplikasi Anda untuk pendapatan selama mungkin, maka jangan refactor dengan menggunakan teknik desain perangkat lunak yang baik, dan biarkan "cukup baik" sendirian. Jika Anda ingin mengembangkan aplikasi Anda untuk menawarkan lebih banyak layanan dan mendapatkan lebih banyak pendapatan, maka Anda harus membayar dan memperbaiki kode tersebut. Dia memilih untuk pergi dengan yang pertama. C'est la vie.

Jika ayah Anda tidak merasakan sakitnya duplikasi data dan integritas data yang lemah sekarang, dia akan melakukannya nanti, dan baru kemudian dia akan mengetahui nilai dari apa yang Anda katakan.

Saya pikir jawaban untuk pertanyaan Anda terutama tergantung pada seberapa penting praktik medisnya adalah aplikasi ini. Apakah ia akan menyimpan di sana hanya beberapa data pasien yang menurutnya berguna atau gangguan fungsi aplikasi ini mungkin memiliki konsekuensi parah? Jika itu mungkin memiliki konsekuensi yang parah, maka dia seharusnya tidak melakukannya tetapi karena kita tidak hidup di dunia yang sempurna meyakinkannya bahwa itu bukan ide yang baik mungkin masalah yang sama sekali berbeda.

Karena Anda adalah konsultan pengembang, saya sarankan menawarkan bantuan padanya dalam QA dan proses pengujian. Dengan cara ini Anda akan menjaga hubungan yang baik dengan ayah Anda karena Anda "membantunya" tetapi pada saat yang sama Anda dapat memastikan bahwa aplikasinya melakukan apa yang seharusnya dilakukan atau bahkan menemukan masalah yang tidak akan dapat ia selesaikan. jadi dia akan mencari solusi yang lebih profesional.

BTW Saya telah melihat cukup banyak aplikasi mengerikan yang melakukan pekerjaan mereka dan tidak ada penjelasan mengapa itu mengerikan akan meyakinkan siapa pun untuk membuat perubahan nyata di dalamnya.

Sebagai seorang insinyur perangkat lunak yang baru saja pensiun untuk penyedia layanan kesehatan nirlaba besar, saya sangat menyarankan mencari rumah sakit atau praktik besar di dekatnya yang dapat dengan biaya yang wajar memungkinkannya untuk berbagi sistem rekam medis elektronik mereka yang memenuhi persyaratan untuk inisiatif Meaningful Use. (dan program insentif pemerintah lainnya).

Saya menyadari bahwa "Epic" ( http://Epic.com ) mendukung pelanggan mereka memungkinkan penyedia yang lebih kecil untuk berbagi sistem mereka, dan saya membayangkan beberapa pesaing mereka juga. Cerner adalah pesaing terbesar mereka, tetapi beberapa yang lain dibahas di http://www.beckershospitalreview.com/healthcare-information-technology/50-things-to- know-about-epic-cerner-meditech-mckesson-athenahealth-and- other-major-ehr-vendor.html

Ada 75% subsidi dari CMS untuk pembagian semacam itu. Kami memberikan subsidi kepada klien kami dengan membuat harga berlangganan 25% dari biaya kami.