Làm Business Analyst Trong Healthcare – Chuyện Trong Nghề

Bài viết được chia sẻ từ chuyên gia Business Analyst trong lĩnh vực Healthcare

Khi nghe tới từ Healthcare, nhiều bạn mới vào nghề BA thường nghĩ ngay đến hình ảnh bệnh viện hiện đại, bác sĩ mặc áo blouse trắng đi qua lại, hệ thống máy móc “xịn sò” và quy trình chăm sóc bệnh nhân mượt như trong phim. Nhưng nếu bạn thật sự bước chân vào vai trò Business Analyst trong lĩnh vực healthcare, bạn sẽ thấy câu chuyện khác… rất khác.

Đây là những chia sẻ “chân thực” từ kinh nghiệm của mình – một BA đã lăn lộn vài năm với các dự án IT healthcare, từ hệ thống quản lý bệnh viện (Hospital Management System – HMS), hồ sơ bệnh án điện tử (Electronic Health Record – EHR), cho tới các dự án tích hợp chuẩn HL7, FHIR, hay telemedicine.

Ngày đầu đi onsite bệnh viện và cú sốc thực tế

Nhớ lần đầu mình đi onsite ở một bệnh viện đối tác tại Quận Nam Từ Liêm, Hà Nội. HR trước khi đi bảo “Anh chỉ cần phỏng vấn vài bác sĩ, điều dưỡng để lấy requirement thôi, dễ mà anh”. Ờ… nghe dễ. Nhưng thực tế thì:

• 9h sáng mình tới, bác sĩ đầu tiên bảo: “Em chờ chút, anh đang khám nốt ca này họ đến sớm”.
• 10h, điều dưỡng bảo: “Chị đang đo huyết áp cho bệnh nhân”.
• 11h, trưởng khoa bảo: “Anh đang đi hội chẩn, để chiều nhé!”

→ Ơ, ngày đầu onsite của mình dành 80% thời gian ngồi ở… căng tin bệnh viện uống trà đá

Kiến thức cơ bản khi làm BA ngành healthcare đó là: bạn phải linh hoạt lịch làm việc và xác định rằng việc “hẹn phỏng vấn stakeholder” không bao giờ chuẩn giờ 100%. Trong tài liệu requirement, hãy luôn note lại bối cảnh và hạn chế về thời gian để team dev hiểu vì sao yêu cầu có thể thay đổi.

Yêu cầu dự án Healthcare: Đừng bao giờ nghĩ nó “đơn giản”

Bạn nghĩ “Chỉ cần thêm một nút in đơn thuốc” là xong?

Không đâu. Một nút in đơn thuốc trong healthcare có thể liên quan tới:

• Quy định của Bộ Y tế.
• Khả năng kết nối với máy in chuyên dụng trong khoa.
• Quy trình duyệt đơn thuốc giữa bác sĩ – điều dưỡng – dược sĩ.
• Tích hợp với kho thuốc để kiểm tra tồn.
• Chuẩn HL7 để gửi thông tin sang hệ thống bảo hiểm.

Một lần, mình viết user story kiểu:

“As a doctor, I want to print a prescription so that I can give it to the patient.”

Product Owner đọc xong bảo: “Story này thiếu acceptance criteria, thiếu flow”. Bác sĩ đọc xong bảo: “Cái này thiếu chữ ký điện tử”. Dev đọc xong bảo: “Máy in của khoa này không hỗ trợ font Unicode”.

→  Kết quả: Từ 1 nút bấm, team mất 3 tuần mới xong.

UX trong bệnh viện: Tại sao những thiết kế “sách vở” thường thất bại ngay lập tức?

Làm BA healthcare không chỉ ngồi trước máy tính vẽ flowchart. Bạn phải hiểu đời sống bệnh viện:

• Vì sao bác sĩ thích nhập dữ liệu bằng bàn phím cơ thay vì màn hình cảm ứng (vì đeo găng tay).
• Vì sao điều dưỡng hay copy-paste ghi chú từ Word vào hệ thống (vì không tin tưởng hệ thống lưu tự động).
• Vì sao kho thuốc chỉ cập nhật tồn kho vào cuối ngày (vì người quản lý kho không rảnh ngồi máy tính cả ngày).

Chính mấy điều nhỏ đó quyết định UX thực tế của hệ thống. Nếu bạn chỉ thiết kế theo sách vở mà không nhìn vào môi trường thật, fail là chắc.

Chuẩn HL7, FHIR – Cơn ác mộng của BA mới dấn thân

Nếu bạn chưa từng nghe HL7 hay FHIR, thì xin chúc mừng – bạn vẫn còn “ngây thơ” trong healthcare. Hai chuẩn này là cách mà hệ thống y tế trao đổi dữ liệu với nhau. Nhưng đọc spec của chúng thì… như đọc văn cổ.

Ví dụ: Một bản tin HL7 gửi thông tin xét nghiệm máu có hơn 50 field, nhiều field chỉ giải thích bằng… 3 chữ viết tắt. Đọc mà như đang giải mã mật thư.

Ngày đầu mình hỏi senior dev: 

Anh ơi, cái này gửi JSON được không?

Anh dev cười: 

JSON chỉ là một dạng bọc thôi, em ạ. Quan trọng là hiểu message structure, segment, field. Chuẩn HL7 là một thế giới riêng.

→ Kết quả: Mình mất 1 tuần chỉ để dịch 10 trang spec thành flow dễ hiểu cho QA test.

Kỹ năng mềm quan trọng hơn bạn nghĩ

Khi làm BA trong healthcare, bạn không chỉ “nói chuyện với dev” mà còn phải:

• Nói chuyện với bác sĩ, điều dưỡng, dược sĩ, nhân viên kho, lễ tân, bảo vệ…
• Viết tài liệu cho PO, đọc luật y tế cho compliance officer, báo cáo cho CEO bệnh viện.

Mỗi nhóm nói một “ngôn ngữ” khác nhau. BA phải dịch tất cả sang cùng một ngôn ngữ yêu cầu phần mềm.

Ví dụ: 

Bác sĩ nói: “Hệ thống cần cảnh báo dị ứng thuốc ngay khi nhập đơn”.

Dev cần biết: “Trigger nào? Check từ bảng nào? So sánh code thuốc thế nào?”

BA phải là cầu nối, vừa hiểu được ngôn ngữ y khoa, vừa biết dịch sang ngôn ngữ kỹ thuật.

Tình huống “đời” nhất: UAT ở bệnh viện

Một buổi test hệ thống ở khoa cấp cứu. Bác sĩ nhập thử bệnh nhân tên “Nguyễn Xuân Trường”, click Save.

Màn hình báo lỗi: “Patient already exists”.

Bác sĩ nhìn mình: “Em ơi, bệnh nhân trùng tên là chuyện bình thường. Em phải check cả ngày sinh, giới tính nữa”.

Mình quay sang QA: “Ghi bug nhé”. QA gật đầu, nhưng 5 phút sau một bác sĩ khác nhập “Nguyễn Bá Hưng” vẫn báo trùng. Hóa ra dev hard-code luôn “Nếu trùng họ thì báo lỗi”…

Bài học SEO-friendly: Testing trong healthcare cần nhiều real-life scenario hơn tưởng tượng. Không dùng dữ liệu “đẹp” để test, mà phải dùng dữ liệu “bẩn” y như thực tế bệnh viện.