Bagaimana Menyelamatkan Proyek Perangkat Lunak Layanan Kesehatan Setelah Kegagalan Vendor

Bukankah menyenangkan ketika perangkat lunak layanan kesehatan Anda akhirnya dikembangkan, dan Anda menghitung mundur menuju peluncuran besarnya?

Namun kemudian Anda terus mendengar, “Kita hanya perlu dua minggu lagi untuk menyelesaikannya.” Dan parahnya mereka sudah mengatakan hal itu selama enam bulan.

Jika kedengarannya familier, kami mendengarkan Anda. Sejumlah besar proyek perangkat lunak perawatan kesehatan gagal hanya karena vendor yang salah menjalankannya. Faktanya, penelitian menunjukkan bahwa hingga 70% proyek teknologi perawatan kesehatan gagal karena pembengkakan biaya, kegunaan yang buruk, atau adopsi yang rendah.

Kami telah dipanggil berkali-kali untuk menyelamatkan aplikasi yang benar-benar keluar jalur. Integrasi EHR yang gagal, portal pasien yang kikuk, sistem yang tidak dapat digunakan oleh siapa pun, kami telah memperbaiki semuanya.

Namun kami di sini bukan untuk melontarkan kata-kata kasar yang menyalahkan vendor.

Di blog ini, kami akan menguraikan cara memperbaiki perangkat lunak layanan kesehatan yang tidak berfungsi oleh vendor sebelumnya dan bagaimana Anda dapat meluncurkannya kembali dengan sukses.

Mari kita mulai.

Betapa Vendor Buruk Membunuh Proyek Perangkat Lunak Layanan Kesehatan

Proyek perangkat lunak layanan kesehatan harus dikembangkan dengan presisi dan hati-hati.

Organisasi perlu mengambil sudut pandang strategis untuk mendiagnosis akar penyebab kegagalan, membantu mereka lebih memahami vendornya dan membuat pilihan yang lebih cerdas.

Berikut sekilas kekacauan yang dihadapi banyak tim layanan kesehatan.

1. Tidak Ada Penemuan, Hanya Pengiriman

Banyak vendor langsung melakukan pengembangan tanpa menginvestasikan cukup waktu dalam penemuan.

Mereka melewatkan langkah-langkah penting, seperti wawancara pemangku kepentingan dan alur kerja serta pelingkupan peraturan. Hasilnya, seperti yang diharapkan, adalah perangkat lunak yang terlihat bagus di atas kertas namun gagal dalam praktiknya. 

Contoh Nyata:

Girard Medical Center di Kansas ingin menerapkan sistem EHR dan menandatangani kontrak senilai $2,9 juta dengan Cerner, salah satu vendor EHR terkemuka.

Vendor tidak pernah sepenuhnya memahami ukuran atau alur kerja rumah sakit, dan sistemnya tidak pernah diterapkan.

Rumah sakit telah menunggu lebih dari satu setengah tahun, kehilangan lebih dari $1 juta, dan kehilangan insentif federal.

Berdasarkan pengajuan Girard, mereka mengakui bahwa pihak rumah sakit telah beberapa kali memberikan pemberitahuan kepada Cerner dan tidak menepati janjinya. Ini adalah kasus klasik melewatkan penemuan dan membangun secara buta. (Sumber)

2. Nol Konteks Layanan Kesehatan

Layanan kesehatan tidak seperti fintech atau ritel. Perusahaan ini memiliki ekosistem standarnya sendiri, seperti FHIR, HL7, dan HIPAA, yang mengatur bagaimana aliran data dan privasi dilindungi.

Vendor tanpa konteks ini menciptakan bom waktu kepatuhan.

Dalam konteks ini, Pete Peranzo, Salah Satu Pendiri Imagination , berbagi, "Hambatan terbesar yang dihadapi perusahaan dalam menerapkan aplikasi layanan kesehatan ini adalah kepatuhan. Ada begitu banyak kepatuhan sehingga memperlambat segalanya."

Contoh Nyata:

Peluncuran Departemen Urusan Veteran AS dan Oracle Cerner EHR mengungkap kesenjangan ini secara dramatis.

Sistem ini mengarahkan lebih dari 11.000 pesanan pasien ke “antrean yang tidak diketahui”, sehingga mengakibatkan keterlambatan dalam perawatan dan dokumentasi kerugian pasien.

Cacat tersebut disebut sebagai kegagalan nyata dan disebabkan oleh kurangnya pemahaman domain dan ketelitian pengujian.

Sumber:Laporan DOTMed

3. Komunikasi dan Transparansi yang Buruk

Apa yang terjadi jika komunikasi terputus?

Kepercayaan terkikis, dan seringkali, ketika klien menyadari ada sesuatu yang salah, biasanya sudah terlambat.

Contoh Nyata:

Sebuah rumah sakit dalam studi kasus ResearchGate yang diterbitkan kembali menggunakan alur kerja kertas setelah peluncuran EHR gagal. Penyebabnya bukan hanya kode yang buruk; itu adalah komunikasi yang buruk.

Ketika pengembang berhenti memperbarui pemangku kepentingan, kepemimpinan tidak terlihat, dan rasa frustrasi pengguna tidak terdengar hingga keseluruhan proyek gagal.

Sumber:Studi ResearchGate

4. Kode Pintasan dan Hutang Teknis

Karena terburu-buru memenuhi tenggat waktu yang tidak realistis, vendor sering kali “memperbaikinya” dengan perbaikan cepat.

Namun dalam layanan kesehatan, pintasan tersebut tidak hanya merusak perangkat lunak, tetapi juga membahayakan keselamatan pasien.

Contoh Nyata:

Selama penerapan Oracle Cerner di VA, penyelidikan internal mengungkapkan adanya patch teknis dan modul yang belum teruji yang memicu kegagalan alur kerja besar.

Pesanan hilang, peringatan gagal, dan dokter kehilangan kepercayaan pada sistem. Utang teknis yang diakibatkannya menghabiskan biaya jutaan dolar untuk melepasnya.

Sumber:Laporan NextGov

5. Mirage MVP

Janji “MVP cepat” bisa saja menipu. Vendor memberikan sesuatu yang terlihat dapat digunakan, namun kurang tangguh untuk lingkungan layanan kesehatan di dunia nyata. 

Contoh Nyata:

Sebuah startup kesehatan yang membangun platform pemantauan pasien jarak jauh segera meluncurkan MVP. Vendor menggunakan API yang tidak patuh, mengabaikan standar FHIR. Ketika rumah sakit akhirnya siap untuk menguji coba sistem ini, pengujian interoperabilitasnya gagal.

Seluruh produk harus dibangun kembali dari awal, dan hal ini ternyata menjadi pelajaran yang mahal.

👉 Intinya

Kebanyakan proyek perangkat lunak layanan kesehatan yang gagal tidak hanya gagal dalam semalam; mereka runtuh secara diam-diam di bawah proses yang buruk.

Faktor-faktor lain, seperti komunikasi yang buruk dan prioritas yang salah, juga berkontribusi terhadap kegagalan ini. Setiap penundaan, jalan pintas, dan salah langkah bertambah hingga sistem dan kepercayaan runtuh.

💡 Wawasan Imajinasi

Mengenai kesalahan paling umum yang dilakukan para pemimpin layanan kesehatan ketika memilih vendor pengembangan perangkat lunak, Pete menggarisbawahi, "Salah langkah dalam pengadaan, RFP yang terburu-buru, memprioritaskan biaya dibandingkan kemampuan, dan mengabaikan keahlian kepatuhan adalah kesalahan umum yang dapat berdampak buruk pada proyek perangkat lunak layanan kesehatan."

Pete menambahkan, "Hal terbesar yang pernah kami alami \[Imajinasi] adalah bahwa perbedaan antara kami dan perusahaan lain adalah bahwa banyak dari perusahaan ini, terutama di bidang ini, mereka akan membangunkan Anda sebuah sistem dan kemudian menyewakannya kepada Anda. Jadi, secara teknis, Anda tidak memiliki seluruh produknya."

Ia menyimpulkan, "Anda memerlukan vendor yang memiliki pengalaman khusus bekerja di bidang layanan kesehatan, menangani persetujuan FDA dan kepatuhan HIPAA, namun juga vendor yang tidak mengorbankan pengalaman dan kecepatan pengguna."

Apa Hal Berbeda yang Dilakukan Pengembang Perangkat Lunak Layanan Kesehatan Hebat?

Bagi para pemimpin layanan kesehatan yang siap memanfaatkan momen ini, mengembangkan perangkat lunak layanan kesehatan yang tahan masa depan sangatlah penting. Menemukan mitra yang andal dan ahli dapat membuat perbedaan besar.

Berikut sekilas peluang yang dapat Anda peroleh dengan partner yang tepat yang memandu project software perawatan kesehatan Anda.

1. Penemuan-Pertama, Selalu

Mitra teratas memiliki proses sistematis untuk mengajukan pertanyaan sulit. Proses penemuannya mendetail, membantu memahami proyek secara menyeluruh sebelum menulis satu baris kode pun.

Mereka menginvestasikan waktu untuk memahami alur kerja, kebutuhan pengguna, dan batasan peraturan. Pekerjaan latar belakang ini membantu memastikan bahwa pembangunan dimulai dengan landasan yang kokoh.

2. Pemikiran yang Dipimpin oleh Kepatuhan

Mereka merancang dengan HIPAA, PHI, dan validasi klinis yang dibangun sejak awal, bukan ditambahkan setelahnya.

3. Dokumentasi dan Kepemilikan yang Jelas

Semua pemangku kepentingan memiliki visibilitas, yang dijamin melalui repositori kode yang transparan.

Selain itu, para mitra mengerjakan serah terima terstruktur dan kolaborasi terbuka. Langkah-langkah ini diambil untuk memastikan akuntabilitas di seluruh siklus hidup proyek.

4. Empati untuk Pengguna Akhir

Setiap fitur terkait dengan alur kerja klinis atau pasien, bukan hanya kenyamanan developer, sehingga membuat perangkat lunak benar-benar dapat digunakan di lingkungan dunia nyata.

5. Pemikiran Jangka Panjang

Arsitektur dirancang dengan hati untuk memastikan skalabilitas dan pemeliharaan. Tim pengembangan tidak akan pernah membuat proyek perangkat lunak layanan kesehatan untuk sprint jangka pendek atau perbaikan cepat.

Saat membangun kembali proyek perangkat lunak layanan kesehatan yang gagal, Pete membagikan hal berbeda yang dilakukan tim Imagination. Pete menegaskan kembali, "Tim Imaginovation membedakan dirinya dari perusahaan lain terutama melalui kepemilikan dan kendali atas perangkat lunak yang mereka kembangkan. Tidak seperti banyak vendor yang membangun sistem dan menyewakannya, Imaginovation memastikan bahwa kliennya memiliki seluruh kekayaan intelektual (IP) produk. Pendekatan ini memberi klien hak kepemilikan penuh, memungkinkan fleksibilitas dan kontrol yang lebih baik atas perangkat lunak, terutama jika mereka perlu melakukan transisi dari vendor sebelumnya."

Dia menggarisbawahi maksudnya melalui studi kasus Everflex, sistem perangkat lunak perawatan kesehatan khusus yang berhasil dibangun kembali oleh tim Imaginovation. Kasus ini melibatkan kemitraan dengan Movement for Life, sebuah perusahaan terapi fisik praktik swasta yang unik, untuk merekonstruksi perangkat lunak mereka secara efektif— menunjukkan keahlian Imaginovation dalam memberikan solusi menyeluruh dan berkualitas tinggi.

Everflex menunjukkan kemampuan Imaginovation untuk merevitalisasi dan meningkatkan sistem perangkat lunak layanan kesehatan, menunjukkan kemahiran tim dalam mengelola proyek yang kompleks dan membalikkan solusi perangkat lunak lama atau bermasalah untuk klien layanan kesehatan.

 Cara Memperbaiki Proyek Layanan Kesehatan yang Rusak demi Kebaikan

Inilah cara jitu untuk menyelamatkan dan mengamankan proyek perangkat lunak layanan kesehatan yang gagal di masa depan.

Langkah 1:Audit Proyek yang Ada

Anda tidak dapat memperbaiki tanpa mengetahui apa yang perlu diperbaiki.

Oleh karena itu, merupakan ide bagus untuk melakukan audit menyeluruh baik pada aspek teknis maupun kepatuhan.

Di antara faktor-faktor yang memerlukan audit adalah kualitas kode, infrastruktur, dan tata kelola data. Anda dapat memberikan pemikiran untuk mengidentifikasi apa yang dapat diselamatkan dan apa yang termasuk dalam utang teknis.

Ingatlah untuk memeriksa peninjauan kontrak, dokumentasi, dan kontrol akses.

👉 Poin penting: Ini akan membantu untuk mendapatkan gambaran yang jelas tentang sejauh mana penyelamatan tersebut, sehingga Anda dapat mengatasinya.

Langkah 2:Pertimbangkan Kembali Mitra Pembangunan Anda

Saat memilih mitra pengiriman yang tepat, kita harus ingat bahwa ini adalah keputusan yang strategis. Sebaiknya jangan menganggapnya sebagai latihan pengadaan.

Ajukan pertanyaan yang mengungkapkan kemampuan nyata:

• Bagaimana kepatuhan layanan kesehatan tertanam dalam arsitektur Anda?
• Siapa pemilik kode dan IP?
• Bagaimana proses penemuan dan penyerahan Anda?

👉 Perhatikan tanda bahaya:

Ada tanda-tanda bahaya yang harus diwaspadai, seperti akuntabilitas yang tidak jelas atau proses yang lemah. Tanda bahaya lainnya adalah komunikasi yang mengelak.

👉 Pola pikir:

Saat memilih mitra, ingatlah bahwa fokusnya harus pada upaya mewujudkan mitra transformasi jangka panjang.

Langkah 3:Mendefinisikan Ulang Penemuan

Pada tahap ini, Anda harus mengambil alih proyek-proyek yang rusak yang seringkali didasarkan pada penemuan yang buruk dan berupaya untuk mengulanginya. Sebaiknya konfirmasi ulang tujuan bisnis, alur kerja, dan hasil klinis.

Semua pemimpin, mulai dari klinis, operasional, hingga TI, harus selaras. Selain itu, fokusnya adalah menentukan titik pemeriksaan kepatuhan dan jalur penting sebelum desain dimulai.

👉 Wawasan: Perlu dicatat bahwa penemuan yang kuat mencegah 80% biaya pembangunan kembali di kemudian hari.

Langkah 4:Rencanakan, Jangan Tambalan

Pada tahap selanjutnya, akan membantu untuk mengadopsi peta jalan pemulihan terstruktur yang berfokus pada stabilisasi proyek perangkat lunak. Tim pengembangan kemudian dapat bekerja sama untuk mendesain ulang proyek tersebut.

Saat tahapan mulai terbentuk, seseorang perlu melakukan pemindahan. Pada tahap ini, penting untuk memprioritaskan area berisiko tinggi, termasuk integritas data dan pengalaman pengguna.

Aspek lain yang perlu dikerjakan adalah mengalokasikan anggaran untuk validasi dan pengujian, selain coding.

👉 Wawasan Imajinasi:

Pengalaman Imagination adalah bahwa tim sering kali menghabiskan lebih sedikit waktu untuk membangun kembali sistem dengan benar dibandingkan terus-menerus menambal sistem yang cacat.

Langkah 5:Desain Ulang dan Kembangkan dengan Cara yang Benar

Saat mendesain ulang, ingatlah untuk memodernisasi proyek perangkat lunak, perhatikan skalabilitas. Sangat penting untuk melakukan pemeriksaan ketat terhadap fitur keamanan gedung dan mempertimbangkan keberlanjutan.

Cara yang bagus adalah dengan menggunakan sprint tangkas dengan pencapaian yang transparan. Tim pengembangan dapat menyematkan pemantauan kepatuhan sejak hari pertama.

Di setiap tahap, dokumentasikan semua keputusan teknis dan desain.

👉 Keunggulan imajinasi:

Di Imagination, kami menegakkan akuntabilitas developer, memastikan transparansi kepemilikan, dan menjaga tata kelola di seluruh proses pembangunan.

Langkah 6:Validasi, Uji, dan Kelola

Fase QA dan Pengujian sangat penting, dan proyek perangkat lunak harus melalui validasi yang ketat dengan pengawasan jangka panjang.

Vendor harus memastikan proyek melalui pemeriksaan kepatuhan QA dan HIPAA/FDA yang berkelanjutan. Akan sangat menyenangkan jika ada audit independen sebelum produksi.

Dalam hal tata kelola yang berkelanjutan, pastikan untuk menyertakan:

• Audit kepatuhan rutin
• Protokol manajemen perubahan
• Pelacakan kinerja vendor

Pengambilan Akhir:

Proyek layanan kesehatan yang rusak dapat dihidupkan kembali, namun hanya dengan audit yang disiplin, kemitraan yang transparan, dan tata kelola yang dibangun sejak awal.

Kerangka kerja pemulihan Imaginovation yang telah terbukti memastikan bahwa penerapan Anda berikutnya aman, terukur, dan dibuat agar tahan lama.

Penutup:Vendor Anda Gagal, Bukan Visi Anda

Ketika sebuah proyek gagal, Anda dapat memikirkan apakah strategi Anda salah atau mempertimbangkan kembali apakah Anda telah memilih vendor yang salah.

Kabar baiknya: banyak organisasi layanan kesehatan telah membangun kembali sistem yang lebih kuat setelah mengalami kemunduran dengan mengambil tindakan dengan tenang, menilai kembali apa yang salah, dan menyelaraskan tujuan bisnis dengan penyampaian teknologi.

Jika Anda juga menghadapi proyek perangkat lunak layanan kesehatan yang gagal atau terhenti, Anda dapat memulai dengan audit cepat. Tim kami di Imajinasi dapat membantu Anda menemukan hal-hal yang dapat diperbaiki dan menghidupkan kembali visi yang Anda mulai.

Kami memiliki pengalaman luas dalam membangun, mengintegrasikan, dan menskalakan solusi yang tepat dengan percaya diri.

Mari kita bicara.