Regulasi RME, Pesta Vendor, dan Dilema Infrastruktur: Menyiapkan SIMRS di Tengah Arus Wajib Satu Sehat

Regulasi RME, Pesta Vendor, dan Dilema Infrastruktur: Menyiapkan SIMRS di Tengah Arus Wajib Satu Sehat

Layar monitor di ruang IT rumah sakit kini tak hanya menampilkan dashboard pasien, tetapi juga deadline regulasi: Rekam Medis Elektronik (RME) yang harus terhubung dengan Satu Sehat Kemenkes—sebuah tugas yang membuat panik tidak hanya pada tim IT, tetapi juga pada manajemen yang harus memilih vendor di tengah hiruk-pikuk penawaran.

Aku baru saja keluar dari rapat di sebuah rumah sakit daerah. Ruangannya masih berbau kopi dan kecemasan. Direktur rumah sakit itu—sebut saja Pak Hendra—memegang tiga proposal SIMRS yang tebalnya masing-masing seperti novel. "Semua bilang compatible dengan Satu Sehat," katanya sambil menggeleng. "Tapi harganya beda 300 juta sampai 1,2 miliar. Dan IT saya bilang, infrastruktur kita harus upgrade dulu, nambah lagi setengah miliar."

Di meja, ada tumpukan brosur vendor. Warna-warni. Klaim-klaim besar. "Telah terintegrasi dengan Satu Sehat." "Memenuhi standar RME terbaru." "Cloud-ready." "On-premise dengan keamanan maksimal."

Tapi yang menarik perhatianku justru notulensi rapat sebulan lalu yang tergeletak di samping. Ditandai dengan stabilo kuning: "Keluhan staf IGD: loading SIMRS lambat saat peak hour. Pasien antre, sistem loading."

Lapisan Pertama: Tekanan Regulasi yang Berdetak Seperti Bomb

Regulasi RME dan Satu Sehat itu seperti bom waktu dengan dua jenis detonator. Pertama, detonator administrasi: denda, teguran, bahkan izin operasional bisa bermasalah. Kedua, detonator moral: pasien berhak atas rekam medis elektronik yang terintegrasi, terutama saat rujukan antar-fasilitas kesehatan.

Tapi di lapangan, dua detonator ini sering dipisahkan. Manajemen rumah sakit biasanya fokus pada yang pertama—takut sanksi. Sementara tim medis (seharusnya) peduli pada yang kedua—kualitas layanan.

Hasilnya? Keputusan dipicu oleh ketakutan, bukan visi. "Pokoknya harus selesai sebelum deadline Kemenkes," kata Pak Hendra. Kalimat itu menghapus pertanyaan-pertanyaan penting seperti: "Sistem baru ini akan membantu dokter bekerja lebih baik, atau justru menambah beban administratif?"

Yang lucu—atau tragis—standar "compatible dengan Satu Sehat" itu sendiri masih banyak interpretasinya. Vendor A bilang compatible berarti bisa ekspor data dalam format tertentu. Vendor B bilang compatible berarti real-time sync dua arah. Vendor C bilang compatible dengan tambahan modul khusus seharga 200 juta lagi.

Dan tidak ada yang berani bertanya: "Bagaimana kalau nanti standarnya berubah lagi?" Karena jawabannya pasti: "Kami akan update dengan versi berikutnya." Yang artinya: "Siap-siap bayar lagi."

Lapisan Kedua: Banjir Tawaran di Pasar yang Panik

Vendor SIMRS sekarang seperti sales asuransi di musim bencana. Mereka tahu calon pelanggannya sedang panik. Dan kepanikan adalah kondisi ideal untuk penjualan.

Aku mengamati pola presentasi vendor-vendor ini. Mereka punya script yang hampir mirip:

1. Slide tentang "urgensi regulasi" (dengan logo Kemenkes besar-besar)
2. Slide "kami sudah terdaftar di Kemenkes" (sertifikat yang kadang cuma daftar, bukan approval)
3. Demo sistem yang selalu lancar (dengan data dummy 10 pasien, bukan 10.000)
4. Testimoni dari rumah sakit "X" (yang seringkali baru implementasi fase 1)
5. Penawaran harga dengan diskon "khusus deadline ini"

Tapi yang jarang mereka tunjukkan:

- Performa sistem dengan 100 user concurrent
- Waktu respons saat koneksi internet rumah sakit sedang trouble
- Biaya maintenance tahun ke-3 sampai ke-5
- Proses migrasi data dari sistem lama (yang sering jadi biaya tersembunyi terbesar)

Seorang teman yang bekerja di vendor SIMRS besar pernah bercerita: "Kami punya dua versi demo. Versi untuk manajemen (fokus pada dashboard dan reporting). Dan versi untuk tim IT (fokus pada arsitektur dan API). Tapi yang selalu diminta adalah versi pertama."

Artinya: pembeli sering membeli berdasarkan apa yang terlihat, bukan berdasarkan bagaimana sistem itu benar-benar bekerja.

Lapisan Ketiga: Infrastruktur—Penyakit Kronis yang Diabaikan

Ini bagian paling menyakitkan. Banyak rumah sakit berpikir: "Beli software saja, sisanya urusan IT." Tapi software mahal tanpa infrastruktur yang memadai seperti mobil sport di jalan berbatu.

Ambil contoh bandwidth. SIMRS modern butuh koneksi stabil. Tapi di banyak daerah, koneksi internet masih seperti curahan hujan—kadang deras, kadang gerimis, kadang mati sama sekali. Vendor akan bilang: "Minimum 10 Mbps dedicated." Realitas di lapangan? SHARE 10 Mbps dengan 50 device lain.

Atau server. Proposal vendor biasanya menyebutkan spesifikasi minimal. Tapi "minimal" itu artinya "bisa jalan, belum tentu nyaman." Seperti bilang "mobil ini minimal bisa sampai tujuan," tanpa menyebutkan bahwa AC-nya mati dan mesinnya berisik.

Dan ada biaya tersembunyi yang paling sering terlupakan: listrik dan pendingin. Server rack yang panas butuh ruang server dengan cooling yang baik. Itu berarti AC khusus, mungkin genset cadangan. Tambahan biaya puluhan juta per tahun yang tidak masuk dalam proposal software.

Pak Hendra menunjukkan ruang server rumah sakitnya. Satu rak kecil di pojok ruang administrasi. "Ini sudah penuh," katanya. "Kalau tambah server untuk SIMRS baru, harus bangun ruang baru. Itu berarti renovasi."

Renovasi fisik. Bukan dalam proposal vendor mana pun.

Dilema Cloud vs On-Premise: Pilihan antara Kewalahan Sekarang atau Nanti

Vendor sekarang banyak menawarkan solusi cloud. "Tidak perlu server mahal," kata mereka. "Bayar bulanan, semua kami urus."

Tapi coba tanyakan detail:

- Data disimpan di server mana? (banyak yang di Singapore atau bahkan US—latency masalah)
- SLA (Service Level Agreement) berapa? 99.5% uptime berarti bisa down 43 jam per tahun
- Backup dan recovery procedure seperti apa?
- Bagaimana kalau internet rumah sakit putus? (ada yang bilang "gunakan backup 4G"—tambah biaya lagi)

On-premise punya masalah sendiri: beban maintenance, upgrade hardware, keamanan fisik. Tapi setidaknya, ketika sistem lambat, kamu tahu persis siapa yang harus dicari: tim IT sendiri.

Yang sering terjadi: rumah sakit memilih hybrid tanpa sadar. Data utama di cloud, tapi untuk transaksi harian butuh server lokal agar cepat. Hasilnya? Kompleksitas ganda. Biaya ganda. Masalah ganda.

Cerita dari Lapangan: SIMRS yang Jadi Beban, Bukan Solusi

Aku berkunjung ke rumah sakit lain yang sudah implementasi SIMRS baru setahun lalu. Kepala IT-nya—Ibu Ratna—mengeluh: "Dulu waktu demo, semua cepat. Sekarang di produksi, setiap jam 10 pagi—saat poli mulai penuh—sistem mulai lambat. Dokter marah. Perawat stres."

Apa penyebabnya? Setelah investigasi:

1. Database design tidak optimal untuk concurrent access tinggi
2. Cache mechanism tidak di-enable karena takut makan memory
3. Koneksi ke Satu Sehat dilakukan sync real-time yang blocking proses lain
4. Antivirus di client PC melakukan scan real-time pada setiap akses database

"Vendor bilang itu masalah infrastruktur kami," kata Ibu Ratna. "Tapi waktu kami tanya solusi spesifik, mereka suruh upgrade server. Padahal server kami baru setahun."

Siklus menyakitkan: beli software → ada masalah → disuruh upgrade hardware → masih ada masalah → disuruh beli module tambahan → dan seterusnya.

Pertanyaan yang Seharusnya Diajukan (Tapi Sering Tidak)

Berdasarkan pengamatan, ini daftar pertanyaan kritis yang seharusnya ditanyakan ke vendor, tapi jarang:

1. Tentang performa:
- Bisa demo dengan 5000 data pasien dan 50 user concurrent?
- Apa bottleneck paling umum di instalasi lain?
- Monitoring tools seperti apa yang disediakan?

2. Tentang integrasi:
- API documentation lengkap? Bisa diakses sebelum membeli?
- Sudah integrasi dengan alat medis apa saja? (EKG, lab analyzer, dll)
- Mekanisme error handling saat koneksi ke Satu Sehat putus?

3. Tentang sustainability:
- Berapa total cost of ownership 5 tahun? (termasuk license renewal, support, upgrade)
- Pelatihan untuk tim IT internal termasuk apa saja?
- Exit strategy: bagaimana kalau mau ganti vendor nanti? Data bisa diekspor dengan mudah?

Yang terjadi justru sebaliknya. Pertanyaan yang diajukan sering: "Diskonnya berapa?" "Bisa cair cepat nggak dananya?" "Bisa tandatangan kontrak besok?"

Jebakan "Checklist Compliance" vs "Usability Sehari-hari"

Ada perbedaan besar antara sistem yang "compliant dengan regulasi" dan sistem yang "membantu pekerjaan sehari-hari."

Sistem compliant mungkin bisa generate laporan untuk Kemenkes dengan sempurna. Tapi jika untuk input satu resep butuh 5 klik dan loading 10 detik, dokter akan benci sistem itu. Dan dokter yang benci akan cari jalan pintas: minta asisten yang input, atau tulis di kertas dulu baru diinput nanti.

Hasilnya? Data tidak real-time. Tujuan RME—memiliki data akurat dan timely—justru dikalahkan oleh sistem yang terlalu rumit.

Idealnya, compliance dan usability berjalan bersama. Tapi dalam tekanan deadline, usability sering dikorbankan. "Pokoknya compliant dulu, nanti di-update lagi," kata vendor. Tapi "nanti" itu sering tidak pernah datang.

Peran Tim IT yang Terjepit

Bayangkan jadi tim IT rumah sakit saat ini. Di satu sisi, manajemen minta sistem baru secepatnya. Di sisi lain, staf medis minta sistem yang tidak mengganggu kerja mereka. Di tengah, vendor menjanjikan sesuatu yang sulit diverifikasi.

Dan tim IT harus hidup dengan sistem itu bertahun-tahun setelah vendor pergi. Mereka yang akan ditelepon tengah malam saat sistem down. Mereka yang disalahkan ketika dokter tidak bisa akses data.

Tapi dalam proses pemilihan, suara tim IT sering kurang didengar. "Itu urusan teknis, biar vendor yang jawab," kata manajemen. Padahal merekalah yang paling paham infrastruktur existing, constraint, dan kultur kerja rumah sakit.

Seorang kepala IT rumah sakit swasta bilang: "Saya sudah bilang dari awal butuh waktu 6 bulan untuk persiapan infrastruktur. Tapi direktur bilang harus jalan dalam 3 bulan karena takut deadline. Hasilnya? Kita implementasi setengah-setengah. Masalahnya numpuk sekarang."

Strategi Bertahan (Bukan Sekedar Memilih)

Jadi, apa yang bisa dilakukan rumah sakit di tengah tekanan tiga lapis ini?

1. Pisahkan urgency dan importance.
Deadline regulasi itu urgent. Tapi sistem yang sustainable itu important. Jangan korbankan important untuk urgent. Mungkin perlu phase approach: implementasi bertahap yang memenuhi regulasi minimum dulu, lalu perbaiki secara incremental.

2. Libatkan end-user sejak awal.
Bukan cuma manajemen dan IT. Dokter, perawat, admin poli—mereka yang akan pakai sehari-hari. Bikin focus group discussion. Tanya pain point mereka dengan sistem lama. Minta mereka ikut demo dan beri feedback.

3. Audit infrastruktur dulu sebelum putuskan software.
Seperti mau beli mobil, cek jalan dulu. Apakah butuh SUV atau sedan cukup? Audit bandwidth, server capacity, jaringan internal. Hasil audit ini jadi dasar requirement, bukan sebaliknya.

4. Minta reference site yang SEJENIS.
Jangan puas dengan testimoni di slide. Minta kunjungi rumah sakit dengan skala dan tipe similar yang sudah pakai sistem itu minimal 1 tahun. Tanya masalah apa yang mereka hadapi, bagaimana vendor support-nya.

5. Siapkan budget tersembunyi.
Kalau total cost yang dihitung 1 miliar, siapkan 1.5 miliar. Karena selalu ada unexpected cost: training tambahan, customization minor, infrastruktur tambahan yang baru ketahuan saat implementasi.

Masa Depan: Sistem yang Hidup atau Beban yang Membatu?

Beberapa tahun lagi, kita akan melihat dua tipe rumah sakit. Pertama, rumah sakit yang SIMRS-nya jadi tulang punggung operasional—sistem yang benar-benar membantu. Kedua, rumah sakit yang SIMRS-nya jadi beban—sistem yang dipakai karena terpaksa, dengan workaround di mana-mana.

Perbedaannya tidak terletak pada merek software yang dipilih. Tapi pada proses seleksi dan implementasinya. Pada seberapa jujur rumah sakit menilai kemampuan sendiri. Pada seberapa berani mereka menolak tawaran yang terlalu bagus untuk menjadi kenyataan.

Pak Hendra akhirnya memutuskan untuk menunda keputusan dua minggu. "Saya minta tim IT buat proof of concept dulu dengan dua vendor top," katanya. "Test dengan data real kita. Lihat bagaimana performanya."

Itu langkah kecil. Tapi penting. Karena dalam dunia yang dipenuhi klaim dan janji, bukti nyata adalah satu-satunya mata uang yang berlaku.

Pada akhirnya, di balik daftar spesifikasi server dan benchmark kecepatan, sukses tidaknya SIMRS dan RME ini akan diukur dari dampak paling nyata di lapangan: apakah alur layanan di rumah sakit menjadi lebih lancar, atau justru terhambat oleh kompleksitas sistem baru yang dipaksakan oleh regulasi?

Tanya-Jawab Santai

Q: Jadi vendor mana yang paling recommended?
A: Tidak bisa jawab spesifik karena setiap rumah sakit kebutuhan dan konteksnya beda. Tapi prinsipnya: pilih vendor yang transparan tentang limitation-nya, bukan yang cuma jual janji. Vendor yang berani bilang "ini tidak bisa kami lakukan" lebih bisa dipercaya daripada yang bilang "semua bisa".

Q: Cloud atau on-premise yang lebih baik?
A: Tergantung. Kalau internet rumah sakit stabil dan tim IT terbatas, cloud mungkin lebih manageable. Tapi kalau sering putus atau ada concern data privacy kuat, on-premise dengan managed service bisa jadi middle ground. Intinya: jangan terjebak dikotomi, cari solusi yang match dengan reality di tempat.

Q: Berapa bandwidth minimal untuk SIMRS?
A: Tidak ada angka sakti. Tergantung jumlah user concurrent dan fitur yang digunakan. Tapi aturan praktis: hitung kebutuhan per user (misal 100 kbps), kali jumlah user peak, kali 1.5 untuk safety margin. Dan yang lebih penting dari bandwidth: latency dan stability.

Q: Apakah harus ganti semua hardware lama?
A: Tidak selalu. Banyak sistem bisa jalan di hardware existing dengan optimasi. Tapi jangan paksa hardware terlalu tua. Audit dulu: mana yang masih adequate, mana yang memang harus diganti. Prioritaskan server database dan storage.

Q: Bagaimana memastikan vendor tidak "angkat kaki" setelah implementasi?
A: Masukkan SLA jelas di kontrak. Bukan cuma uptime, tapi juga response time untuk critical issue. Dan minta dokumen lengkap (source code escrow untuk custom development, admin manual, architecture diagram). Tapi yang paling penting: bangun relationship, bukan sekadar transaksi.

Q: Kalau dana terbatas, fitur apa yang diprioritaskan?
A: Core clinical workflow dulu: pendaftaran, rekam medis, farmasi, billing. Reporting dan analytics bisa tahap kedua. Dan untuk integrasi Satu Sehat, pastikan mekanisme sync-nya efisien—tidak perlu real-time kalau membebani sistem, batch nightly mungkin cukup untuk memulai.

RME Regulations, Vendor Frenzy, and Infrastructure Dilemmas: Preparing Hospital Information Systems Amid Mandatory Satu Sehat Currents

Screens in hospital IT rooms now display not just patient dashboards, but regulatory deadlines: Electronic Medical Records (RME) that must connect with the Ministry of Health's Satu Sehat—a task causing panic not only among IT teams, but also management who must choose vendors amidst the chaos of offers.

I just left a meeting at a regional hospital. The room still smelled of coffee and anxiety. The hospital director—let's call him Mr. Hendra—held three thick HIS proposals each resembling novels. "All say compatible with Satu Sehat," he said while shaking his head. "But prices differ by 300 million to 1.2 billion. And my IT says our infrastructure needs upgrading first, add another half billion."

On the table, stacks of vendor brochures. Colorful. Big claims. "Already integrated with Satu Sehat." "Meets latest RME standards." "Cloud-ready." "On-premise with maximum security."

But what caught my attention was last month's meeting minutes lying beside them. Highlighted in yellow: "ER staff complaints: HIS loading slow during peak hours. Patients queueing, system loading."

First Layer: Regulatory Pressure Ticking Like Bombs

RME and Satu Sehat regulations are like time bombs with two detonator types. First, administrative detonator: fines, warnings, even operational permits could be problematic. Second, moral detonator: patients have rights to integrated electronic medical records, especially during referrals between health facilities.

But in the field, these two detonators are often separated. Hospital management usually focuses on the first—fear of sanctions. While medical teams (should) care about the second—service quality.

The result? Decisions driven by fear, not vision. "Just must finish before the Ministry's deadline," said Mr. Hendra. That sentence erases important questions like: "Will this new system help doctors work better, or actually add administrative burden?"

What's funny—or tragic—the "compatible with Satu Sehat" standard itself still has many interpretations. Vendor A says compatible means can export data in specific format. Vendor B says compatible means real-time two-way sync. Vendor C says compatible with additional special module costing 200 million more.

And no one dares ask: "What if the standard changes again later?" Because the answer would surely be: "We'll update with the next version." Which means: "Prepare to pay again."

Second Layer: Flood of Offers in a Panicked Market

HIS vendors now are like insurance salespeople during disaster season. They know their potential customers are panicking. And panic is ideal selling condition.

I observe patterns in these vendor presentations. They have almost similar scripts:

1. Slides about "regulatory urgency" (with huge Ministry of Health logos)
2. Slides "we're registered with the Ministry" (certificates sometimes just listings, not approvals)
3. System demos that always run smoothly (with 10 dummy patients, not 10,000)
4. Testimonials from hospital "X" (often just phase 1 implementation)
5. Price offers with "special deadline" discounts

But what they rarely show:

- System performance with 100 concurrent users
- Response times when hospital internet connection is troubled
- Maintenance costs years 3 to 5
- Data migration process from old systems (often becoming the biggest hidden cost)

A friend working at a major HIS vendor once shared: "We have two demo versions. Version for management (focusing on dashboards and reporting). And version for IT teams (focusing on architecture and API). But what's always requested is the first one."

Meaning: buyers often purchase based on what looks good, not how the system actually works.

Third Layer: Infrastructure—Chronic Illness Ignored

This is the most painful part. Many hospitals think: "Just buy the software, the rest is IT's business." But expensive software without adequate infrastructure is like a sports car on rocky roads.

Take bandwidth example. Modern HIS needs stable connections. But in many regions, internet connections are still like rainfall—sometimes heavy, sometimes drizzle, sometimes completely dead. Vendors will say: "Minimum 10 Mbps dedicated." Field reality? SHARED 10 Mbps with 50 other devices.

Or servers. Vendor proposals usually mention minimum specifications. But "minimum" means "can run, not necessarily comfortable." Like saying "this car can minimally reach the destination," without mentioning the AC is broken and the engine is noisy.

And there's the most frequently forgotten hidden cost: electricity and cooling. Hot rack servers need server rooms with good cooling. That means special AC, maybe backup generators. Additional costs tens of millions per year not included in software proposals.

Mr. Hendra showed his hospital's server room. One small rack in the corner of an admin room. "This is already full," he said. "If adding servers for new HIS, must build new room. That means renovation."

Physical renovation. Not in any vendor's proposal.

Cloud vs On-Premise Dilemma: Choice Between Overwhelmed Now or Later

Vendors now offer many cloud solutions. "No need expensive servers," they say. "Monthly payment, we handle everything."

But ask for details:

- Where is data stored? (many in Singapore or even US—latency problems)
- What's the SLA? 99.5% uptime means can be down 43 hours per year
- What's the backup and recovery procedure?
- What if hospital internet disconnects? (some say "use 4G backup"—more costs)

On-premise has its own problems: maintenance burden, hardware upgrades, physical security. But at least, when the system is slow, you know exactly who to find: your own IT team.

What often happens: hospitals choose hybrid unconsciously. Main data in cloud, but daily transactions need local servers for speed. Result? Double complexity. Double costs. Double problems.

Field Story: HIS Becoming Burden, Not Solution

I visited another hospital that implemented new HIS a year ago. Their IT head—Mrs. Ratna—complained: "During demo, everything was fast. Now in production, every 10 AM—when polyclinics get crowded—system starts slowing. Doctors angry. Nurses stressed."

Cause? After investigation:

1. Database design not optimal for high concurrent access
2. Cache mechanism not enabled for fear of memory consumption
3. Connection to Satu Sehat using real-time sync blocking other processes
4. Antivirus on client PCs doing real-time scans on every database access

"Vendor says it's our infrastructure problem," said Mrs. Ratna. "But when we ask for specific solutions, they tell us to upgrade servers. Even though our servers are just a year old."

Painful cycle: buy software → problems occur → told to upgrade hardware → still problems → told to buy additional modules → and so on.

Questions That Should Be Asked (But Often Aren't)

Based on observations, these critical questions should be asked vendors, but rarely are:

1. About performance:
- Can demo with 5000 patient data and 50 concurrent users?
- What are the most common bottlenecks at other installations?
- What monitoring tools are provided?

2. About integration:
- Complete API documentation? Accessible before purchasing?
- Already integrated with what medical devices? (EKG, lab analyzers, etc.)
- Error handling mechanism when Satu Sehat connection disconnects?

3. About sustainability:
- What's the 5-year total cost of ownership? (including license renewal, support, upgrades)
- What does training for internal IT teams include?
- Exit strategy: what if wanting to change vendors later? Can data be exported easily?

What happens is the opposite. Questions often asked: "How much discount?" "Can funds be disbursed quickly?" "Can sign contract tomorrow?"

Trap of "Checklist Compliance" vs "Daily Usability"

There's a big difference between systems "compliant with regulations" and systems "helping daily work."

Compliant systems might perfectly generate reports for the Ministry. But if inputting one prescription needs 5 clicks and 10 seconds loading, doctors will hate that system. And doctors who hate will find shortcuts: ask assistants to input, or write on paper first then input later.

Result? Data not real-time. The goal of RME—having accurate and timely data—is actually defeated by overly complicated systems.

Ideally, compliance and usability go together. But under deadline pressure, usability is often sacrificed. "Just compliant first, we'll update later," vendors say. But "later" often never comes.

IT Teams Caught in the Middle

Imagine being a hospital IT team now. On one side, management wants new systems quickly. On the other, medical staff want systems not disrupting their work. In the middle, vendors promise something hard to verify.

And IT teams must live with that system for years after vendors leave. They'll get called midnight when systems crash. They'll get blamed when doctors cannot access data.

But in selection processes, IT team voices are often unheard. "That's technical matters, let vendors answer," management says. Even though they understand existing infrastructure, constraints, and hospital work culture best.

A private hospital IT head said: "I said from the start need 6 months for infrastructure preparation. But the director said must run in 3 months fearing deadlines. Result? We implement half-heartedly. Problems pile up now."

Survival Strategies (Not Just Choosing)

So, what can hospitals do amid this three-layer pressure?

1. Separate urgency and importance.
Regulatory deadlines are urgent. But sustainable systems are important. Don't sacrifice important for urgent. Maybe need phased approach: gradual implementation meeting minimum regulations first, then improve incrementally.

2. Involve end-users from the start.
Not just management and IT. Doctors, nurses, polyclinic admins—they'll use it daily. Create focus group discussions. Ask their pain points with old systems. Have them join demos and give feedback.

3. Audit infrastructure first before deciding software.
Like buying a car, check the road first. Need SUV or sedan enough? Audit bandwidth, server capacity, internal networks. Audit results become requirement basis, not vice versa.

4. Request SIMILAR reference sites.
Don't settle for slide testimonials. Request visits to similar scale and type hospitals using that system at least 1 year. Ask what problems they face, how vendor support is.

5. Prepare hidden budgets.
If total cost calculated is 1 billion, prepare 1.5 billion. Because there's always unexpected costs: additional training, minor customizations, additional infrastructure only discovered during implementation.

Future: Living Systems or Fossilized Burdens?

A few years from now, we'll see two hospital types. First, hospitals where HIS becomes operational backbone—systems truly helping. Second, hospitals where HIS becomes burden—systems used out of obligation, with workarounds everywhere.

The difference lies not in chosen software brands. But in selection and implementation processes. In how honestly hospitals assess their own capabilities. In how brave they are rejecting offers too good to be true.

Mr. Hendra finally decided to postpone decision for two weeks. "I asked IT team to do proof of concept first with two top vendors," he said. "Test with our real data. See how performance is."

That's a small step. But important. Because in a world filled with claims and promises, tangible proof is the only valid currency.

Ultimately, behind server specification lists and speed benchmarks, the success or failure of this HIS and RME will be measured from the most tangible impact in the field: whether hospital service workflows become smoother, or are actually hindered by complexities of new systems forced by regulations.

Casual Q&A

Q: So which vendor is most recommended?
A: Can't answer specifically because each hospital has different needs and contexts. But principle: choose vendors transparent about their limitations, not just selling promises. Vendors daring to say "this we cannot do" are more trustworthy than those saying "everything possible."

Q: Cloud or on-premise better?
A: Depends. If hospital internet stable and IT team limited, cloud might be more manageable. But if frequent disconnections or strong data privacy concerns, on-premise with managed service could be middle ground. Point: don't get trapped in dichotomy, find solutions matching your location's reality.

Q: Minimum bandwidth for HIS?
A: No magic number. Depends on concurrent users and features used. But practical rule: calculate needs per user (e.g., 100 kbps), times peak users, times 1.5 for safety margin. And more important than bandwidth: latency and stability.

Q: Must replace all old hardware?
A: Not always. Many systems can run on existing hardware with optimization. But don't force overly old hardware. Audit first: what's still adequate, what truly needs replacement. Prioritize database servers and storage.

Q: How to ensure vendors don't "disappear" after implementation?
A: Include clear SLA in contracts. Not just uptime, but response times for critical issues. And request complete documentation (source code escrow for custom development, admin manuals, architecture diagrams). But most important: build relationships, not just transactions.

Q: If funds limited, what features prioritized?
A: Core clinical workflow first: registration, medical records, pharmacy, billing. Reporting and analytics can be phase two. And for Satu Sehat integration, ensure sync mechanisms are efficient—no need real-time if burdening system, nightly batch might suffice to start.