KINH NGHIỆM TRIỂN KHAI PHẦN MỀM

Sàn phẩm phần mềm khi đưa vào thực tế mới nói lên được giá trị hữu dụng. Những thiết kế ban đầu của phần mềm hầu như sẽ phải thay đổi hết khi đưa vào thực tế. Do sự phong phú, đa dạng về hình thức, tổ chức, quy trình, chuyên khoa… mà phần mềm áp dụng cho từng bệnh viện sẽ rất khác nhau. Để đáp ứng đúng yêu cầu của bệnh viện, nhà cung cấp phải “cắt may" tính năng theo từng khách hàng riêng, khó có thể áp dụng chung một hệ thống phần mềm chung một cách đại trà.

16 năm triển khai phần mềm vào thực tế từ bệnh viện lớn đến bệnh viện nhỏ, tôi sẽ liệt kê ra những bài học kinh nghiệm dưới đây.

1. Các bệnh viện có quy mô khác nhau không thể dùng chung phần mềm.

Bệnh viện đa khoa huyện PQ trang bị phần mềm QLBV, đáp ứng yêu cầu căn bản của quản lý chuyên môn bệnh viện. Khi bệnh viện đa khoa tỉnh KG đến tham khảo thì mời nhà cung cấp phần mềm đến để trang bị hệ thống. Giám đốc bệnh viện tỉnh KG nghĩ rằng phần mềm đã có sẵn và chạy thực tế tại BV huyện Phú Quốc rồi thì chỉ việc áp vào bệnh viện tỉnh là có thể chạy được. Dự trù thời gian triển khai là 6 tháng. 

Tuy nhiên, thực tế không như dự đoán. BV huyện có vài mươi bác sĩ trong khi bệnh viện tỉnh có vài trăm bác sĩ. BV huyện tiếp đón một trăm bệnh nhân mỗi ngày trong khi bệnh viện tỉnh tiếp đón 2500 bệnh nhân mỗi ngày. Danh mục dịch vụ ở bệnh viện tỉnh chỉ vài trăm chi tiết trong khi ở bệnh viện tỉnh đến vài nghìn… Do đó, khi áp dụng phần mềm tuyến quận huyện cho bệnh viện tuyến tỉnh, nhà cung cấp đã phải mất đến gần 2 năm trời để xây dựng, chỉnh sửa mới đáp ứng được yêu cầu hoạt động thực tế của bệnh viện tuyến tỉnh.

Tương tự như vậy, sau khi hoàn tất phần mềm cho BV tỉnh KG, nhà cung cấp phần mềm tiến hành cài đặt phần mềm cho bệnh viện chuyên khoa Tâm Thần TPHCM. Bệnh viện này mặc dù có số lượng bệnh nhân và số lượng danh mục dịch vụ không nhiều bằng BV tỉnh Kiên Giang nhưng có nhiều cơ sở nằm ở các vị trí địa lý khác nhau. Yêu cầu đặt ra là cả 3 cơ sở phải sử dụng chung một hệ thống để quản lý. Bệnh nhân từ cơ sở này chuyển sang cơ sở khác vẫn dùng chung một hệ thống bệnh án. Đây là bài toán mới mà nhà cung cấp phải đáp ứng. Điều kiện này bắt buộc NCC phải tái cấu trúc dữ liệu phần mềm và sửa đổi cách lập trình. Ngoài ra còn các yêu cầu đặc biệt của một bệnh viện chuyên khoa như thiết lập các bệnh án chuyên khoa tâm thần, chuyên khoa tâm lý, các thang điểm đánh giá tâm lý trẻ em… Hay phải sửa đổi lại cách tính viện phí theo từng đợt đối với bệnh nhân tâm thần ở dài ngày trong bệnh viện….

Bài học rút ra là: “Không thể áp dụng một phần mềm QLBV cho các bệnh viện có quy mô khác nhau”.

2. Nhiều lý do bệnh viện không sử dụng phần mềm

Trừ khi các bệnh viện được lệnh từ SYT hay BYT phải sử dụng phần mềm để gửi báo cáo thanh toán BHYT thì các bệnh viện phải làm theo. Trước đó, nếu không có áp lực này thì hầu như việc áp dụng phần mềm là miễn cưỡng. Trước hết là phản ứng từ nhân viên, bác sĩ

• Tại một bệnh viện Phụ Sản ở Hải Phòng, khi lập trình viên khảo sát để triển khai phần mềm siêu âm thì bác sĩ siêu âm gầm lên: "Chúng mày muốn cài phần mềm để kiểm soát công việc của ông đấy hả?". Thế là LTV thụt mất. Ở một số bệnh viện, các bác sĩ lợi dụng tài nguyên của bệnh viện để làm lợi cá nhân, họ sợ bị kiểm soát và ra sức ngăn cản triển khai phần mềm. Tương tự như vậy, các khoa Xét nghiệm, khoa Dược cũng có vấn đề. Bác sĩ giám đốc BV Việt Tiệp Hải Phòng nói: “Tôi chỉ cần kiểm soát được 50% số liệu ở khoa Xét Nghiệm thôi là cũng đỡ lắm rồi".

Khi phần mềm đã được cài đặt và hướng dẫn sử dụng, bệnh viện không đưa vào sử dụng ngay. Lý do rất buồn cười:

• Bệnh viện còn ấn chỉ xét nghiệm in sẵn, chờ xài cho hết ấn chỉ đó thì mới đưa phần mềm vào sử dụng, kẻo lãng phí.

• Bệnh viện không cấp giấy in cho các khoa, do đó khoa không thể in và vì vậy không dùng phần mềm.

• Bệnh viện có quá ít bệnh nhân: Ví dụ một bệnh viện chuyên khoa Lao và bệnh phổi ở một tỉnh lỵ miền trung du có rất ít bệnh nhân đến khám mỗi ngày. Nhân viên tại bệnh viện cảm thấy việc ghi sổ sách bằng tay cò dễ quản lý hơn là dùng một hệ thống máy tính đồ sộ, rườm ra. Do đó sau khi có một trục trặc nhỏ trên máy chủ thì bệnh viện cũng dẹp luôn hệ thống vi tính.

• Phần mềm không đáp ứng được yêu cầu hoạt động của bệnh viện: bệnh viện trông chờ vào hệ thống phần mềm để xử lý số liệu và cải thiện hiệu quả công việc. Tuy nhiên, phần mềm được lập trình dở, thiếu tính năng, thường xuyên sai số liệu sẽ dẫn đến stress cho người dùng. Sự chịu đựng có giới hạn, đến một lúc nào đó, bệnh viện sẽ phải buông bỏ, chấm dứt hợp đồng với nhà cung cấp.

• Áp lực từ cấp trên: các chính sách của cơ quan chủ quản sẽ góp phần làm cho bệnh viện từ bỏ phần mềm cũ mặc dù bệnh viện vẫn đang xài tốt phần mềm hiện tại. Chính sách này có thể xuất phát từ mong muốn thống nhất sử dụng phần mềm cho toàn khu vực, cũng có thể là sự tác động của lợi ích nhóm. Là một cơ quan chịu sự quản lý của cấp trên, bệnh viện bắt buộc phải tuân thủ theo lệnh trên, tiếp thu một phần mềm thiếu tính năng, non nghiệp vụ mà không dám cãi.

• Từ sự cạnh tranh của đối thủ: trong khi bệnh viện đang sử dụng phần mềm của công ty A một cách ổn định thì công ty B đã ra sức xây dựng một sản phẩm mới có tính năng mới vượt trội, nhiều tiện ích, giá thành rẻ… có đủ sức mạnh để buộc bệnh viện phải từ bỏ phần mềm cũ, chọn phần mềm mới. Điều này tương tự như khách hàng thay đổi điện thoại smart phone thay cho Nokia cùi bắp vậy.

3. Tranh chấp quyền lợi và trách nhiệm giữa khách hàng và nhà cung cấp

Trách nhiệm và quyền lợi được ghi đầy đủ trong hợp đồng, hai bên cùng nhau thực hiện. Tuy nhiên, hầu như việc triển khai thực tế ít khi tuân thủ đúng những gì đã ghi trong hợp đồng. Bệnh viện không thể hình dung ra được hết tính năng phần mềm sẽ mang lại lợi ích gì cho mình. Công ty thiếu kinh nghiệm không hình dung ra hết mức độ khó khăn khi cung cấp phần mềm.

Đối với bệnh viện từng trải, từng sử dụng qua nhiều hệ thống phần mềm khác nhau thì yêu cầu thực tế khắt khe hơn. Bệnh viện thường đòi hỏi những tính năng quen dùng mà phần mềm trước đó đã có, mặc dù tính năng thay thế của phần mềm sau có thể hay hơn. Có thể ví dụ như người đã quen đi xe có cần gạt số không quen với đi xe số tự động. Nhà cung cấp phải thêm những tính năng cũ theo yêu cầu cho đến khi người dùng quen thuộc với tính năng mới.

Theo hợp đồng nguyên tắc thì nhà cung cấp chỉ cung cấp phần mềm có đủ tính năng ghi trong phụ lục và bệnh viện phải cung cấp đầy đủ tài liệu, quy trình, dữ liệu ban đầu để nạp vào hệ thống. Tuy nhiên, hầu hết bệnh viện không tuân thủ trách nhiệm của mình, không củ người giao tiếp, không cung cấp quy trình và chậm hụt trong việc soạn thảo dữ liệu ban đầu hoặc cung cấp dữ liệu ban đầu không đúng chuẩn. Hợp đồng chi tiết không được phổ biến cho nhân viên bệnh viện nên công việc tham gia không ăn khớp nhau. Có bệnh viện chơi xấu cố tình đưa dữ liệu rác để đổ vào hệ thống, gây cản trở cho việc triển khai. Nhà cung cấp muốn triển khai xong hệ thống phải chấp nhận mất thời gian để xử lý đống dữ liệu rác này hoặc phải hối thúc, tranh cãi với bệnh viện về trách nhiệm theo hợp đồng.

Người đại diện của bệnh viện không nắm được quy trình bệnh viện nên cung cấp những quy trình không phù hợp thực tế hoặc chỉ phù hợp khi không dùng máy tính. Qua quá trình triển khai thì thay đổi quy trình liên tục làm nhà cung cấp phải tốn nhiều thời gian để chỉnh sửa quy trình.

Trong khi sử dụng phần mềm, user ở cấp quản lý thường đòi hỏi thêm các báo cáo, thống kê mà mình mới vừa nghĩ ra, yêu cầu nhà cung cấp phải cung cấp thêm. Những yêu cầu phát sinh thêm này làm tốn hao tài nguyên công sức thời gian của công ty nhưng bệnh viện thường lờ đi, xem như trách nhiệm công ty phải làm. Do đó, nhà cung cấp phải có tài liệu ghi rõ về những yêu cầu phát sinh và chi phí kèm theo để hạn chế bớt các yêu cầu vô tội vạ từ phía khách hàng. 

Về mặt phát triển, nhà cung cấp có thiện ý thường sẽ chấp nhận thực hiện các tính năng, những sáng kiến mới mà phần mềm vốn không có sẵn. Những yêu cầu mới này sẽ làm cho phần mềm giàu tính năng hơn, có giá trị hơn. Do đó, NCC sẽ vui vẻ tiếp nhận ý kiến và thực hiện yêu cầu mới. Khi các yêu cầu mới được thực nghiệm, chạy thật trên số liệu thực tế thì những tính năng đó trở thành tài sản của công ty.

4. Chuyện về lợi ích kinh tế sau khi trang bị phần mềm

Bệnh viện đa khoa tỉnh X còn một món nợ khoảng 200 tỷ đồng để lại từ thời giám đốc trước mà không thể xử lý nguyên nhân. Trước đó bệnh viện đã dùng một phần mềm tự viết. Bệnh viện này cũng thường xuyên bị bảo hiểm y tế xuất toán vì sai sót. Công việc ghi bệnh án được thực hiện bằng tay nên không thể kiểm soát được sai sót. 

Sau khi áp dụng phần mềm YKHOA.NET vào vận hành thì số nợ kể trên đã được thanh toán hết cho chủ nợ, đồng thời bệnh viện có dư tiền để trả phụ cấp cho nhân viên. 

Bên cạnh đó, bệnh viện cũng xóa sổ tình trạng ùn ứ bệnh án chậm kiểm tra. Trước đó, hồ sơ bệnh án của những bệnh nhân đã xuất viện nhiều đến mức mà 7 nhân viên không thể kiểm tra hết, luôn luôn tồn đọng từ nhiều tuần trước. Việc kiểm tra hồ sơ chỉ mang tính lấy lệ vì bệnh nhân đã xuất viện. Sau khi có phần mềm thì tất cả bệnh án đều được kiểm soát ngay từ trước khi bệnh nhân xuất viện. BV đã thoát được tình trạng bị xuất toán do sai sót chuyên môn.

Bệnh viện Y của Bộ Công An cũng đã gặt hái được những kết quả tương tự như vậy. Sau khi phần mềm được cài đặt, số tiền doanh thu tăng thêm 25% do chống thất thoát và chống xuất toán.

Phần mềm quản lý bệnh viện đã giúp ích cho nhà quản lý không chỉ về tài chính mà còn về chuyên môn, không chỉ chống xuất toán mà còn tăng doanh thu.

Tuy nhiên, có những câu chuyện thành công, cũng có những câu chuyện thất bại. Có bệnh viện lớn ở TPHCM đầu tư 1 triệu đô la Mỹ chỉ cho riêng phần mềm, chọn một công ty có "thương hiệu lớn" để cung cấp, nhưng qua 4 năm, đã quá hạn hợp đồng, hệ thống phần mềm vẫn không thể đưa vào sử dụng và không thể nghiệm thu.