Nghiên cứu phương pháp luận agile và đề xuất áp dụng triển khai bệnh án điện tử

LỜI NÓI ĐẦU Khoa học và ứng dụng của chuyên ngành quản lý dự án và phương pháp luận quản trị dự án – Project Management Methodology, là một trong những lĩnh vực trọng yếu và có thể nói l

BỘ GIÁO DỤC VÀ ĐÀO TẠO TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI

-

PHẠM TRUNG THÀNH

NGHIÊN CỨU PHƯƠNG PHÁP LUẬN AGILE VÀ

ĐỀ XUẤT ÁP DỤNG TRIỂN KHAI BỆNH ÁN ĐIỆN TỬ

LUẬN VĂN THẠC SỸ KỸ THUẬT CÔNG NGHỆ THÔNG TIN

Hà Nội – 2015

BỘ GIÁO DỤC VÀ ĐÀO TẠO TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI

-

PHẠM TRUNG THÀNH

NGHIÊN CỨU PHƯƠNG PHÁP LUẬN AGILE VÀ

ĐỀ XUẤT ÁP DỤNG TRIỂN KHAI BỆNH ÁN ĐIỆN TỬ

Chuyên ngành: CÔNG NGHỆ THÔNG TIN

LUẬN VĂN THẠC SỸ KỸ THUẬT CÔNG NGHỆ THÔNG TIN

NGƯỜI HƯỚNG DẪN KHOA HỌC:

TS PHÙNG VĂN ỔN

HÀ NỘI - 2015

LỜI CAM ĐOAN

Luận văn thạc sỹ này do tôi nghiên cứu và thực hiện dưới sự hướng dẫn

của Thầy giáo TS Phùng Văn Ổn Với mục đích học tập, nghiên cứu để nâng

cao kiến thức và trình độ chuyên môn nên tôi đã làm luận văn này một cách nghiêm túc và hoàn toàn trung thực

Để hoàn thành bản luận văn này, ngoài các tài liệu tham khảo đã liệt kê, tôi cam đoan không sao chép toàn văn các công trình hoặc thiết kế tốt nghiệp của người khác

Hà Nội, tháng 9 năm 2015

Học viên

Phạm Trung Thành

Tôi xin bày tỏ lòng biết ơn chân thành, lời cảm ơn sâu sắc nhất đối với

thầy giáo TS Phùng Văn Ổn đã trực tiếp hướng dẫn, định hướng cho tôi giải

quyết các vấn đề trong luận văn

Tôi cũng xin cảm ơn các bạn, các anh chị em lớp CHBK2013B1 đã đồng hành và cùng giúp đỡ tôi trong quá trình học tập và làm luận văn

Luận văn cũng xin được là lời chia vui với người thân, đồng nghiệp, bạn

bè và các bạn đồng môn hai lớp cao học CHBK2013B1 và CHBK2013B2

MỤC LỤC

MỞ ĐẦU 11

1 CƠ SỞ KHOA HỌC VÀ THỰC TIỄN CỦA ĐỀ TÀI 12

2 MỤC ĐÍCH CỦA ĐỀ TÀI (CÁC KẾT QUẢ CẦN ĐẠT ĐƯỢC) 12

3 BỐ CỤC LUẬN VĂN 13

CHƯƠNG I PHƯƠNG PHÁP LUẬN AGILE 14

I.1 TUYÊN NGÔN AGILE (AGILE MANIFESTO) 15

I.2 ĐẶC TRƯNG AGILE 16

I.2.1 Tính lặp (Iterative) 17

I.2.2 Tính tiệm tiến (Incremental) và tiến hóa (Evolutionary) 17

I.2.3 Tính thích ứng (hay thích nghi – adaptive) 17

I.2.4 Nhóm tự tổ chức và liên chức năng 18

I.2.5 Quản lý tiến trình thực nghiệm (Empirical Process Control) 18

I.2.6 Giao tiếp trực diện (face-to-face communication) 18

I.2.7 Phát triển dựa trên giá trị (value-based development) 19

I.3 CÁC NGUYÊN TẮC VÀ GIÁ TRỊ TRONG AGILE 19

I.3.1 Cá nhân và Sự tương tác 20

I.3.2 Phần mềm Chạy tốt hơn là Tài liệu đầy đủ 22

I.3.3 Cộng tác với khách hàng hơn là thương thảo hợp đồng 22

I.3.4 Phản hồi với thay đổi hơn là bám sát kế hoạch 23

I.3.5 Agile là chiếc ô – Các phương pháp dưới chiếc ô này 24

CHƯƠNG II HTTT BỆNH VIỆN VÀ BỆNH ÁN ĐIỆN TỬ 26

II.1 HIỆN TRẠNG ỨNG DỤNG CNTT TRONG CÁC BỆNH VIỆN26 II.1.1 Cơ cấu hoạt động ngành 26

II.1.2 Hiện trạng và các tồn tại 27

II.1.3 Các giải pháp đã triển khai và khó khăn vướng mắc 32

II.1.4 Kết luận 35

II.2 BỆNH ÁN ĐIỆN TỬ VÀ HTTT BỆNH VIỆN 35

II.2.1 Cấu trúc Bệnh án điện tử 35

II.2.2 HTTT Bệnh viện quản lý BADT 37

II.3 KIẾN TRÚC TỔNG THỂ HTTT BỆNH VIỆN 39

II.3.1 Mô hình tổng thể Hệ thống 41

II.3.2 Hạ tầng phần cứng và mạng 45

II.4 GIẢI PHÁP CHI TIẾT 47

II.4.1 Hệ thống dịch vụ quản lý Bệnh nhân 47

II.4.2 Hệ thống dịch vụ quản lý hàng đợi yêu cầu 49

II.4.3 Hệ thống dịch vụ quản lý Viện phí 52

II.4.4 Hệ thống dịch vụ quản lý Khám chữa bệnh 56

II.4.5 Hệ thống dịch vụ quản lý Hồ sơ bệnh án 57

II.5 MÔ HÌNH PHẦN MỀM 59

II.5.1 Nền tảng công nghệ 59

II.5.2 Các quy chuẩn áp dụng 60

CHƯƠNG III MÔ HÌNH AGILE TRIỂN KHAI BỆNH ÁN ĐIỆN TỬ 61 III.1 ĐẶT VẤN ĐỀ 61

III.2 MÔ HÌNH AGILE CHO PHẦN MỀM 62

III.2.1 Tuân thủ “Tuyên ngôn Agile” 63

III.2.2 Đảm bảo “12 nguyên tắc Agile” 64

III.2.3 Các quy chuẩn áp dụng 66

III.3 MÔ HÌNH AGILE CHO TRIỂN KHAI 67

III.3.1 Tuân thủ các nguyên lý Agile 68

III.3.2 Mô hình triển khai 69

III.4 TRIỂN KHAI BỆNH ÁN ĐIỆN TỬ THEO AGILE 72

KẾT LUẬN 74

TÀI LIỆU THAM KHẢO 77

THUẬT NGỮ

1 Methodology Phương pháp luận, mô hình quản lý phần mềm

2 Agile Phương pháp luận nhanh/gọn, trong quản lý phần

13 HIS Hospital Information System – HTTT Bệnh viện

14 SOA Service-oriented Architecture – Kiến trúc phần

mềm hướng dịch vụ

15 BPM Business Process Management – là khoa học về

quản trị về nâng cao hiệu xuất của tổ chức bằng việc áp dụng tối ưu và quản trị các quy trình nghiệp vụ

16 BPMN Business Process Model and Notation – mô hình

biểu diễn quy trình nghiệp vụ của tổ chức dưới dạng các lược đồ hình khối

17 WCF Windows Communication Foundation – Nền

tảng giao tiếp (dịch vụ) trên nền Microsoft Windows và IIS

18 WF Windows Workflow Foundation – Nền tảng

luồng nghiệp vụ trên nền Microsoft Windows

19 Service Dịch vụ phần mềm, được cung cấp dưới dạng các

dịch vụ Web (Web Service)/WCF, là chuẩn cung cấp phương pháp truyền thông chuẩn toàn cầu giữa các ứng dụng mà không phụ thuộc nền tảng

STT Viết tắt Mô tả

(Windows, *NIX, Browsers, Smart devices, )

20 Interface Các giao diện nghiệp vụ phần mềm được cung

cấp bởi các Service dưới dạng tập hợp các lời gọi hàm từ xa (RPC), các hệ thống cần giao tiếp với nhau sẽ kết nối vào các dịch vụ và yêu cầu dịch

vụ thực hiện công việc đã được định nghĩa từ các giao diện này

21 ESB Enterprise Service Bus – là một mô hình kiến

trúc phần mềm sử dụng cho việc thiết kế và triển khai việc truyền thông/giao tiếp giữa các ứng dụng trong tổ chức được thiết kế theo SOA

22 Site Site – là một đơn vị độc lập trong chuỗi bệnh

viện, có tư cách pháp nhân, vị trí địa lý cũng như

mô hình hoạt động tương đối độc lập với các đơn

vị còn lại

23 Center Center – Trung tâm/SYT/Bộ Y Tế quản lý chung

các bệnh viện con trong chuỗi Chuỗi bệnh viện

sẽ bao gồm liên tiếp nhiều site hoạt động độc lập với nhau Thông qua Center sẽ có mối quan hệ lỏng để đảm bảo sự liên thông dữ liệu trong toàn

hệ thống Center sẽ có được dữ liệu của toàn hệ thống theo gần thời gian thực (độ trễ thấp) để đảm bảo cung cấp cho các site liên quan và việc tổng hợp/thống kê ở tổng thể toàn hệ thống

LỜI NÓI ĐẦU

Khoa học và ứng dụng của chuyên ngành quản lý dự án và phương pháp luận quản trị dự án – Project Management Methodology, là một trong những lĩnh vực trọng yếu và có thể nói là xương sống của xã hội, giúp việc thực thi một tập hợp các công việc bởi một tập thể nhằm đạt được một kết quả dự kiến trong một thời gian xác định; trong tất cả các lĩnh vực của đời sống hằng ngày

từ kinh tế, chính trị chúng ta có thể thấy được dự án hiển hiện ở bất cứ nơi nào Chính vì vậy việc thực hiện một dự án tốt, có phương pháp đúng đắn sẽ đảm bảo không những dự án thành công, mà còn mang lại hiệu quả to lớn, làm tiền

đề cho những dự án tương tự sẽ được tiếp tục, theo đó thúc đẩy cho ngành/lĩnh vực được phát triển cũng như mang lại thành công chung cho xã hội

Trong khi đó, việc áp dụng phần mềm vào trong các lĩnh vực thực sự là một công việc khó khăn và phức tạp, sự phức tạp này ở trong tất cả các đối tượng tham gia vào dự án từ đối tượng thụ hưởng (end-users), đối tượng tài trợ (sponsors), đối tượng thực hiện (members), quy trình nghiệp vụ (business process) cho tới bản thân các cấu thành của phần mềm (software components) Chính vì vậy quản trị dự án phần mềm thực sự là một nghệ thuật, nếu không thì việc thất bại sẽ nhìn thấy rất sớm từ khi mới bắt đầu dự án, hoặc dự án sẽ chỉ được đóng hình thức mà hoàn toàn không có giá trị thực

Quản trị dự án (QTDA) đã được nghiên cứu và ứng dụng rộng rãi, đạt được rất nhiều kết quả khả quan ở trên thế giới cũng như ở Việt Nam Từ đòi hỏi phát sinh trong thực tiễn, QTDA đã được nghiên cứu và ứng dụng từ mức tổng quát rồi đi vào chi tiết cho rất nhiều chuyên ngành hẹp – đã trở thành chuẩn cho chuyên ngành (industry standard), theo đó mang lại thành quả cao cho các nhà quản lý của các lĩnh vực tương ứng – từ chính nhu cầu của các cấp lãnh đạo này, cho tới việc QTDA thực sự mang lại kết quả tốt cho tổ chức mà làm cho việc ứng dụng CNTT trở thành một tất yếu và phát triển mạnh mẽ ở tổ chức đấy

Đối với lĩnh vực y tế, cả trên thế giới lẫn ở Việt Nam, việc nghiên cứu QTDA cho dự án phần mềm chuyên sâu còn rất hạn chế Một vài nơi có ứng dụng nhưng đều dựa trên kinh nghiệm và yêu cầu thực tế góp nhặt lại của chính

tổ chức đấy, rồi áp dụng theo mô hình QTDA tổng quát để đưa vào áp dụng mà chưa có cơ sở khoa học

Phương pháp luận Agile mới ra đời ở trên thế giới mới được hơn 10 năm nay, nhưng đã nhanh chóng phổ dụng và chứng minh được rất nhiều ưu việt,

đặc biệt càng phù hợp với môi trường và năng lực CNTT còn hạn chế của những nước thuộc thế giới thứ 3 cũng như ở Việt Nam Điều này lại càng phù hợp với việc áp dụng cho lĩnh vực y tế, nơi mà ứng dụng CNTT còn nhiều bất cập, manh mún, dàn trải

Xuất phát từ nhu cầu trên, tôi chọn đề tài: “Nghiên cứu phương pháp luận Agile và đề xuất áp dụng triển khai Bệnh án điện tử” cho luận văn của mình

Đưa ra được các đầu vào số liệu cần thiết, theo lộ trình ứng dụng CNTT của tổ chức Khám chữa bệnh để dần xây dựng được một hệ thống cho áp dụng các phương pháp tối ưu trong QTDA phần mềm để tiến tới hệ thống phần mềm tổng thể HIS

Đưa ra các phương pháp luận cho việc khai thác các số liệu, cùng lộ trình tập hợp số liệu, theo đó các nhà quản lý của tổ chức Khám chữa bệnh có được các quyết định phù hợp (hỗ trợ ra quyết định), từ đó điều chỉnh hành vi của các tác nhân, tổ chức; dự báo cho sự tăng trưởng và phát triển của tổ chức; lên kế hoạch cho sự nâng cao chất lượng của toàn hệ thống

Thực hiện khảo sát, tham vấn/tư vấn quy trình/mô hình, ứng dụng Agile ở một số tổ chức khám chữa bệnh, làm việc trực tiếp với các nhà quản lý ở các tổ chức đó để lấy phản hồi và điều chỉnh hệ thống cũng như phương pháp luận cho phù hợp thực tiễn Theo đó kết quả đầu ra không những là phương pháp luận của Agile mà còn là một mô hình thực tế, đã được thử nghiệm, ứng dụng

và phản hồi từ chính thực tế, giúp đem khoa học Agile/ERP thực sự đi vào thực tiễn

Agile/HIS – tham vọng để đặt nền tảng cho một lý thuyết mới, cho một lĩnh vực rất hẹp trên một nền lý thuyết cũ, lớn mà đã ứng dụng thành công trong thực tế Đề tài này ngoài việc thể hiện phạm vi vừa đủ với một đề tài luận văn Cao học, cũng vừa có khả năng ứng dụng thành công trong thực tế và cũng bắt kịp xu thế của Việt Nam hiện tại cũng như trong tương lai gần, đó là mong muốn của toàn dân, mong muốn của cả hệ thống chính trị, là có một hệ thống

Y tế toàn diện, hướng tới người dân, ai cũng có quyền được chăm sóc sức khỏe toàn diện và hướng tới tương lai “giàu tính nhân văn” cho ngành Y tế ở Việt Nam

Với những ý nghĩa thực tiễn đó, luận văn này sẽ nghiên cứu và trình bày phương áp luận Agile và áp dụng vào triển khai hệ thống quản lý Bệnh viện tổng thể từ đó làm cơ sở để áp dụng Bệnh án điện tử triệt để vào cho Bệnh viện

1 CƠ SỞ KHOA HỌC VÀ THỰC TIỄN CỦA ĐỀ TÀI

Trong thực tế thì việc thực hiện dự án ở các cơ sở y tế thường được đi theo một trong 2 hướng:

- Bài bản: Được các hãng ERP/Healthcare lớn đưa vào, họ sẽ áp theo quy

trình QTDA kinh điển của thế giới nhiều chục năm nay là RUP (Rational Unified Process) vào thực hiện cho các dự án triển khai Việc áp dụng quy trình thường sẽ nặng nề và tốn kém nhân lực và kinh phí, yêu cầu các chuyên gia cao cấp nhiều năm kinh nghiệm, cũng như đòi hỏi phía đơn vị thụ hưởng cũng cần phải có năng lực CNTT tương ứng

- Chắp vá: Thường các đơn vị triển khai CNTT ở Việt Nam áp dụng, vì

năng lực của tự thân họ và cũng như năng lực/kinh phí dành cho CNTT của đơn vị thụ hưởng còn khiêm tốn Nên phương án này được áp dụng hết sức tự nhiên, theo nhu cầu (không bài bản) của đơn vị thụ hưởng cũng như năng lực CNTT còn khiêm tốn của các nhà cung cấp nội địa

Agile là một khái niệm tương đối mới với lĩnh vực phần mềm và mới chỉ được áp dụng trong lĩnh vực hẹp là gia công phần mềm cho nước ngoài, thường bởi vì chính những khách hàng đặt hàng và yêu cầu các đơn vị gia công ở Việt Nam cần tuân theo để việc QTDA được thực hiện khoa học và bài bản Việc áp dụng Agile trên thế giới mới được hơn 10 năm nay, nhưng đã nhanh chóng phổ dụng và chứng minh được rất nhiều ưu việt, đặc biệt càng hợp với môi trường và năng lực CNTT còn non yếu của những nước thuộc thế giới thứ 3 cũng như ở Việt Nam Điều này lại càng phù hợp với việc áp dụng cho lĩnh vực y tế, nơi mà hội tụ rất nhiều tri thức của xã hội, nhưng CNTT hiện được coi là yếu kém so với các lĩnh vực tương đồng và luôn là mối quan tâm đặc biệt của các cơ quan quản lý nhà nước nhằm thúc đẩy ứng dụng CNTT cho ngành y tế

2 MỤC ĐÍCH CỦA ĐỀ TÀI (CÁC KẾT QUẢ CẦN ĐẠT ĐƯỢC)

- Nghiên cứu lý thuyết và ứng dụng về Agile trong việc QTDA triển khai

hệ thống ERP tổng thể Tổng hợp lại các phương pháp luận mang tính khái quát trong từng bước ứng dụng Agile vào cho các tổ chức

- Khảo sát, đánh giá và tổng hợp về ứng dụng CNTT trong các bệnh viện ngành y tế (Hệ thống thông tin Bệnh viện – HIS – Hospital Information System) cũng như đánh giá về xu hướng chung của ngành Y tế ở Việt Nam

trong tương lai gần cũng như sự quan tâm và đầu tư của Xã hội cho Y tế của Việt Nam, theo đó định vị được chuyên đề cần nghiên cứu trong bức tranh ứng dụng CNTT tổng thể trong chuyên ngành Y

- Đưa ra mô hình tổng quan về phương pháp luận Agile trong mối quan hệ với HIS, theo đó đánh giá mức độ quan trọng của Agile trong HIS

- Đưa ra các mô hình thu thập và các mô hình tổng hợp thông tin, cũng như các phương pháp khai phá (data mining), tổng hợp thông tin dưới vai trò của người lãnh đạo của tổ chức Từ đó hình thành được một mô hình khung cho Agile

- Đưa ra mô hình và lộ trình ứng dụng về Agile, thực hiện thử nghiệm, sau

đó tiến hành khảo sát để lấy phản hồi, dựa vào đó tiến hành đánh giá lại rồi bổ sung để hoàn thiện phương pháp luận của đề tài

- Tổng hợp lại để đúc kết thành cơ sở khoa học của đề tài và đánh giá về xu hướng ứng dụng Cuối cùng thực hiện đánh giá kết quả đã đạt được, hoàn thiện phương pháp và đưa ra định hướng nghiên cứu chuyên sâu hơn nữa cho đề tài

3 BỐ CỤC LUẬN VĂN

Ngoài phần mở đầu và kết luận, Luận văn được chia ra làm 3 chương cụ thể như sau:

Chương I PHƯƠNG PHÁP LUẬN AGILE

Giới thiệu phương pháp luận Agile cũng như các thành công trong việc khắc phục những điểm yếu trong quy trình phát triển và triển khai phần mềm tới cho khách hàng, theo đó là một trong những cơ sở để hình thành lý thuyết cốt lõi cho đề tài này

Chương II HTTT BỆNH VIỆN VÀ BỆNH ÁN ĐIỆN TỬ

- Khảo sát, đánh giá và tổng hợp về ứng dụng CNTT trong các bệnh viện ngành y tế (Hệ thống thông tin Bệnh viện – HIS – Hospital Information System), cũng như đánh giá về xu hướng chung của ngành Y tế Việt Nam trong tương lai gần

- Trình bày kiến trúc của HTTT Bệnh viện và Bệnh án điện tử, kiến trúc điển hình để có thể áp dụng cho các Bệnh viện ở Việt Nam

Chương III ÁP DỤNG MÔ HÌNH AGILE TRIỂN KHAI BỆNH ÁN ĐIỆN TỬ

Trình bày về áp dụng phương pháp luận Agile, vào xây dựng và triển khai HTTT Bệnh viện trong việc khắc phục các điểm yếu, các vấn đề của ngành được nêu ở chương 2

CHƯƠNG I PHƯƠNG PHÁP LUẬN AGILE

Phát triển phần mềm linh hoạt (Agile software development – gọi tắt là Agile) là một triết lí cùng với nhóm các phương pháp và phương pháp luận phát triển phần mềm dựa trên các nguyên tắc phát triển phân đoạn lặp (iterative) và tăng trưởng (incremental), theo đó nhu cầu và giải pháp tiến hóa thông qua sự hợp tác giữa các nhóm tự quản và liên chức năng Agile thường

sử dụng cách lập kế hoạch thích ứng (adaptive planning), việc phát triển và chuyển giao theo hướng tiến hóa; sử dụng các khung thời gian ngắn và linh hoạt để dễ dàng phản hồi lại với các thay đổi trong quá trình phát triển Ngày nay, triết lí Agile đã vượt xa khỏi khu vực truyền thống của mình là phát triển phần mềm để đóng góp sự thay đổi trong cách thức làm việc, quản lí, sản xuất

ở các ngành khác như sản xuất (manufacturing), dịch vụ, sales, marketing, giáo dục v.v

Mức độ phổ biến của các phương pháp [7]

Thuật ngữ “Agile” chính thức được sử dụng rộng rãi theo cách thống nhất

kể từ khi “Tuyên ngôn Agile” được giới thiệu ra công chúng năm 2001 Nhờ tính linh hoạt, đa dạng và hiệu quả cao, các phương pháp Agile ngày càng trở thành sự lựa chọn hàng đầu của các khách hàng, nhà phát triển, các công ty phát triển phần mềm Theo khảo sát của hãng nghiên cứu thị trường Forrester, mức độ phổ biến của Agile hiện đang ở mức cao nhất, và gấp nhiều lần so với các phương pháp truyền thống như thác nước hay CMMi (xem biểu đồ trên)

Hơn thế, một số phương pháp Agile có xuất xứ và được sử dụng hiệu quả ngoài

phạm vi phát triển phần mềm

I.1 TUYÊN NGÔN AGILE (AGILE MANIFESTO)

Vào tháng 02 năm 2001, mười bảy (17) nhà phát triển phần mềm đã gặp

gỡ nhau ở Snowbird, Utah Resort để thảo luận về các phương pháp phát triển phần mềm gọn nhẹ và linh hoạt Họ đã cùng nhau công bố “Tuyên ngôn phát triển phần mềm linh hoạt” (“Manifesto for Agile Software Development” – gọi tắt là “Tuyên ngôn Agile”) để định nghĩa cách hiểu về phát triển phần mềm linh hoạt Đây là cột mốc quan trọng của Agile Dù trước đó, các phương pháp Agile như XP, Scrum, v.v đã được sử dụng thành công ở rất nhiều nơi, nhưng phải tới khi có sự xuất hiện của “Tuyên ngôn Agile”, cùng với sự ra đời của các hiệp hội chuyên ngành Agile như Agile Alliance hay Scrum Alliance, các phương pháp Agile mới có một sự phát triển vượt bậc Văn bản này rất ngắn,

dễ hiểu, và rất quan trọng vì nó đưa ra các giá trị cốt lõi nhất mà toàn bộ các nhà lý thuyết cũng như những người thực hành Agile tuân thủ; mặc dù các phương pháp họ đề xuất hoặc sử dụng trong thực tiễn có thể rất khác nhau Toàn văn Tuyên ngôn Agile như sau:

Tuyên ngôn Phát triển phần mềm linh hoạt [8]

Chúng tôi đã phát hiện ra cách phát triển phần mềm tốt hơn bằng cách thực hiện nó và giúp đỡ người khác thực hiện

Qua công việc này, chúng tôi đã đi đến việc đánh giá cao:

Cá nhân và sự tương tác hơn là quy trình và công cụ;

Phần mềm chạy tốt hơn là tài liệu đầy đủ;

Cộng tác với khách hàng hơn là đàm phán hợp đồng;

Phản hồi với các thay đổi hơn là bám sát kế hoạch

Mặc dù các điều bên phải vẫn còn giá trị, nhưng chúng tôi đánh giá cao hơn các mục ở bên trái

Bên cạnh đó, các nhà phát triển còn nhấn mạnh mười hai nguyên lý phía sau Tuyên ngôn Agile để giúp các nhà phát triển có được gợi ý trong thực hành

và vận dụng các phương pháp Agile trong thực tiễn Các nguyên lý được liệt kê sau đây:

1) Ưu tiên cao nhất của chúng tôi là thỏa mãn khách hàng thông qua việc Chào đón việc thay đổi yêu cầu, thậm chí rất muộn trong quá trình

phát triển Các quy trình linh hoạt tận dụng sự thay đổi cho các lợi thế cạnh tranh của khách hàng

2) Thường xuyên chuyển giao phần mềm chạy tốt tới khách hàng, từ vài tuần đến vài tháng, ưu tiên cho các khoảng thời gian ngắn hơn

3) Nhà kinh doanh và nhà phát triển phải làm việc cùng nhau hàng ngày trong suốt dự án

4) Xây dựng các dự án xung quanh những cá nhân có động lực Cung cấp cho họ môi trường và sự hỗ trợ cần thiết, và tin tưởng họ để hoàn thành công việc

5) Phương pháp hiệu quả nhất để truyền đạt thông tin tới nhóm phát triển

và trong nội bộ nhóm phát triển là hội thoại trực tiếp

6) Phần mềm chạy tốt là thước đo chính của tiến độ

7) Các quy trình linh hoạt thúc đẩy phát triển bền vững Các nhà tài trợ, nhà phát triển, và người dùng có thể duy trì một nhịp độ liên tục không giới hạn

8) Liên tục quan tâm đến các kỹ thuật và thiết kế tốt để gia tăng sự linh hoạt

9) Sự đơn giản – nghệ thuật tối đa hóa lượng công việc chưa xong, là căn bản

10) Các kiến trúc tốt nhất, yêu cầu tốt nhất, và thiết kế tốt nhất sẽ được làm ra bởi các nhóm tự tổ chức

11) Đội sản xuất sẽ thường xuyên suy nghĩ về việc làm sao để trở nên hiệu quả hơn, sau đó họ sẽ điều chỉnh và thay đổi các hành vi của mình cho phù hợp

Các nguyên lý này, cùng với năm điểm cốt lõi trong "Tuyên ngôn Agile"

sẽ dẫn đường cho các nhà thực hành Agile (Agile practictioner) vận dụng tốt các phương pháp Agile vào thực tiễn

I.2 ĐẶC TRƯNG AGILE

Có rất nhiều phương pháp Agile với các hướng tiếp cận rất khác nhau Bên cạnh các cách thức tổ chức công việc, thiết lập quy trình, các phương pháp Agile còn nghiên cứu và đưa vào sử dụng các công cụ và kỹ thuật đặc thù như công cụ tích hợp liên tục (continuous integration), kiểm thử đơn vị, mẫu thiết

kế, tái cấu trúc, phát triển hướng kiểm thử (TDD), phát triển hướng hành vi (BDD), hay lập trình theo cặp v.v để đảm bảo và gia tăng tính linh hoạt Tuy vậy các phương pháp này chia sẻ nhiều đặc trưng giống nhau cộng tác nhóm chặt chẽ, tổ chức các nhóm tự quản, liên chức năng, tính đáp ứng cao trong suốt vòng đời của dự án

I.2.1 Tính lặp (Iterative)

Dự án sẽ được thực hiện trong các phân đoạn lặp đi lặp lại Các phân đoạn (được gọi là Iteration hoặc Sprint) này thường có khung thời gian ngắn (từ một đến bốn tuần) Trong mỗi phân đoạn này, nhóm phát triển thực hiện đầy đủ các công việc cần thiết như lập kế hoạch, phân tích yêu cầu, thiết kế, triển khai, kiểm thử (với các mức độ khác nhau) để cho ra các phần nhỏ của sản phẩm Các phương pháp Agile thường phân rã mục tiêu thành các phần nhỏ với quá trình lập kế hoạch đơn giản và gọn nhẹ nhất có thể, và không thực hiện việc lập

kế hoạch dài hạn Có phương pháp như Scrum thậm chí sử dụng phương pháp lập kế hoạch just-in-time trong quá trình phát triển Khi đó, thậm chí công việc lập kế hoạch, làm mịn kế hoạch được thực hiện liên tục trong suốt quá trình làm việc

-ơ

Các phân đoạn lặp đi lặp lại trong Agile

I.2.2 Tính tiệm tiến (Incremental) và tiến hóa (Evolutionary)

Cuối các phân đoạn, nhóm phát triển thường cho ra các phần nhỏ của sản phẩm cuối cùng Các phần nhỏ này thường là đầy đủ, có khả năng chạy tốt, được kiểm thử cẩn thận và có thể sử dụng ngay (gọi là potentially shippable product increment of functionality) Theo thời gian, phân đoạn này tiếp nối phân đoạn kia, các phần chạy được này sẽ được tích lũy, lớn dần lên cho tới khi toàn bộ yêu cầu của khách hàng được thỏa mãn Khác với mô hình phát triển Thác nước – vốn chỉ cho phép nhìn thấy toàn bộ các chức năng tại thời điểm kết thúc dự án, sản phẩm trong các dự án Agile lớn dần lên theo thời gian, tiến hóa cho tới khi đạt được trạng thái đủ để phát hành

I.2.3 Tính thích ứng (hay thích nghi – adaptive)

Do các phân đoạn chỉ kéo dài trong một khoảng thời gian ngắn, và việc lập kế hoạch cũng được điều chỉnh liên tục, nên các thay đổi trong quá trình phát triển (yêu cầu thay đổi, thay đổi công nghệ, thay đổi định hướng về mục tiêu v.v.) đều có thể được đáp ứng theo cách thích hợp Ví dụ, trong Scrum – phương pháp phổ biến nhất hiện nay, trong khi nhóm phát triển sản xuất ra các gói phần mềm, khách hàng có thể đưa thêm các yêu cầu mới, chủ sản phẩm (Product Owner) có thể đánh giá các yêu cầu này và có thể đưa vào làm việc trong phân đoạn (được gọi là Sprint trong Scrum) tiếp theo Theo đó, các quy trình Agile thường thích ứng rất tốt với các thay đổi

I.2.4 Nhóm tự tổ chức và liên chức năng

Cấu trúc nhóm Agile thường là liên chức năng (cross-functionality) và tự

tổ chức (self-organizing) Theo đó, các nhóm này tự thực hiện lấy việc phân công công việc mà không dựa trên các mô tả cứng về chức danh (title) hay làm việc dựa trên một sự phân cấp rõ ràng trong tổ chức Các nhóm này cộng tác với nhau để ra quyết định, theo dõi tiến độ, giải quyết các vấn đề mà không chờ mệnh lệnh của các cấp quản lý Họ không làm việc theo cơ chế “mệnh lệnh và kiểm soát” (command and control) Nhóm tự tổ chức có nghĩa là nó đã đủ các

kỹ năng (competency) cần thiết cho việc phát triển phần mềm, do vậy nó có thể được trao quyền để tự ra quyết định, tự quản lí và tổ chức lấy công việc của chính mình để đạt được hiệu quả cao nhất

I.2.5 Quản lý tiến trình thực nghiệm (Empirical Process Control)

Các nhóm Agile ra các quyết định dựa trên các dữ liệu thực tiễn thay vì tính toán lý thuyết hay các tiền giả định (prescription) Việc phân nhỏ dự án thành các phân đoạn ngắn góp phần gia tăng các điểm mốc để nhóm phát triển thu thập dữ kiện cho phép điều chỉnh các chiến lược phát triển của mình Nói cách khác, Agile rút ngắn vòng đời phản hồi (short feedback life cycle) để dễ dàng thích nghi và gia tăng tính linh hoạt Theo thời gian, các chiến lược này sẽ tiến gần đến trạng thái tối ưu, nhờ đó nhóm có thể kiểm soát được tiến trình, và nâng cao năng suất lao động

I.2.6 Giao tiếp trực diện (face-to-face communication)

Một số mô hình phát triển phần mềm dựa rất nhiều vào công việc giấy tờ,

từ việc thu thập yêu cầu người dùng, viết đặc tả hệ thống, các thiết kế hệ thống v.v Agile không phản đối công dụng của công việc tài liệu hóa, nhưng đánh giá cao hơn việc giao tiếp trực diện thay vì gián tiếp thông qua giấy tờ Về yêu cầu của khách hàng, Agile khuyến khích nhóm phát triển trực tiếp nói chuyện với khách hàng để hiểu rõ hơn về cái khách hàng thực sự cần, thay vì phụ thuộc nhiều vào các loại văn bản Trong giao tiếp giữa nội bộ nhóm phát triển với nhau, thay vì một lập trình viên (thực hiện việc mã hóa) và một kỹ sư (thực hiện việc thiết kế) giao tiếp với nhau thông qua bản thiết kế, Agile khuyến khích hai người này trực tiếp trao đổi và thống nhất với nhau về thiết kế của hệ thống và cùng nhau triển khai thành các chức năng theo yêu cầu

Bản thân các nhóm Agile thường nhỏ (ít hơn mười hai người, một nhóm lớn thường được phân nhỏ với cơ chế hợp tác đặc thù để luôn luôn có thông lượng giao tiếp tối đa) để đơn giản hóa quá trình giao tiếp, thúc đẩy việc cộng tác hiệu quả Các dự án lớn muốn dùng Agile thường phải phân thành nhóm

nhỏ đồng thời làm việc với nhau hướng đến một mục tiêu chung Việc này có thể đòi hỏi một số nỗ lực đáng kể trong việc điều phối các mức ưu tiên giữa các nhóm

Các nhóm phát triển thường tạo ra các thói quen và cơ chế trao đổi trực diện một cách thường xuyên Một trong các cơ chế thường thấy là các cuộc họp tập trung hàng ngày (daily meeting, Daily Scrum, standup meeting) Tại đây, tất cả các thành viên được yêu cầu nói rõ cho nhóm của mình biết mình đã làm

gì, đang làm gì, sắp làm gì và đang gặp phải khó khăn nào trong quá trình làm việc Khi cơ chế này được thực hiện hiệu quả, nhóm luôn luôn nắm được tình hình công việc của mình, có các hành động thích hợp để vượt qua các trở lực

để thực hiện thành công mục tiêu của dự án

I.2.7 Phát triển dựa trên giá trị (value-based development)

Một trong các nguyên tắc cơ bản của Agile là “phần mềm chạy tốt chính

là thước đo của tiến độ” Nguyên tắc này giúp nhóm dám loại bỏ đi các công việc dư thừa không trực tiếp mang lại giá trị cho sản phẩm Ví dụ, một nhóm thấy rằng có thể không cần phải viết ra tất cả các thiết kế của hệ thống, mà họ chỉ cần phác thảo các thiết kế này lên bảng, rồi cùng nhau triển khai các chức năng của hệ thống Nhưng nếu như chủ sản phẩm quyết định rằng, khi chuyển giao sản phẩm, nhóm phát triển phải kèm theo thiết kế chi tiết của hệ thống vì chúng chiếm 20% giá trị của dự án theo yêu cầu của khách hàng, và vì khách hàng cần nó để chứng minh tính đúng đắn của các chức năng, và để phát triển tiếp các phân hệ tiếp theo của sản phẩm thì nhóm phát triển sẽ phải thực hiện việc tài liệu hóa đầy đủ

Để vận hành được cơ chế “làm việc dựa trên giá trị”, nhóm Agile thường làm việc trực tiếp và thường xuyên với khách hàng (hay đại diện của khách hàng), cộng tác trực tiếp với họ để biết yêu cầu nào có độ ưu tiên cao hơn, mang lại giá trị hơn sớm nhất có thể cho dự án Nhờ đó các dự án Agile thường giúp khách hàng tối ưu hóa được giá trị của dự án Một cách gần như trực tiếp, Agile gia tăng đáng kể độ hài lòng của khách hàng

I.3 CÁC NGUYÊN TẮC VÀ GIÁ TRỊ TRONG AGILE

Phát triển Linh hoạt (Agile Development) làm một thuật ngữ có nguồn gốc từ Tuyên ngôn phát triển phần mềm linh hoạt (Agile Manifesto - Tuyên ngôn Agile), tuyên ngôn này được soạn thảo năm 2001 bởi một nhóm gồm các nhà sáng tạo Scrum, Extreme Programming (XP), Dynamic Systems Development Method (DSDM - Phương pháp phát triển hệ thống linh động),

và Crystal; đại diện của phát triển hướng-tính-năng (feature-driven) và một vài

nhà lãnh đạo khác trong lĩnh vực công nghiệp phần mềm Tuyên ngôn Agile đã tổng kết ra một số giá trị và nguyên tắc chung, phổ quát cho tất cả các phương pháp luận về linh hoạt đang tồn tại độc lập tại thời điểm đó Văn bản này đưa

ra bốn giá trị cốt lõi cho phép các nhóm đạt được hiệu suất cao

 Cá nhân và sự tương tác

 Cung cấp phần mềm chạy tốt

 Cộng tác với khách hàng

 Phản hồi với các thay đổi

Các giá trị cốt lõi này còn được hỗ trợ bởi 12 nguyên tắc như đã trình bày

ở phần trước

Những giá trị đó không chỉ là thứ mà các tác giả của Tuyên ngôn Agile dự định cung cấp ra để phục vụ cho tuyên ngôn để rồi sau đó đi vào quên lãng Chúng là các giá trị căn cứ vào để làm việc Bản thân mỗi phương pháp linh hoạt đều tiếp cận các giá trị trên theo các cách thức khác nhau, nhưng tất cả các phương pháp này đều có tiến trình và thực hành cụ thể để nuôi dưỡng một hoặc nhiều trong số các giá trị đó

I.3.1 Cá nhân và Sự tương tác

Cá nhân và sự tương tác giữa họ là cốt yếu để nhóm đạt được hiệu suất cao Các nghiên cứu về “bão hòa truyền thông” trong một dự án cho thấy rằng, khi không có vấn đề trong truyền thông, nhóm có thể thực hiện công việc tốt hơn 50 lần so với mức trung bình trong lĩnh vực của mình Để tạo điều kiện cho truyền thông, các phương pháp linh hoạt thường xuyên sử dụng chu trình thanh-tra-và-thích-nghi Chu trình này có thể diễn ra hàng phút với lập trình cặp (pair-programming), hàng giờ với tích hợp liên tục (continuos integration), hàng ngày với standup metting (đứng họp), hàng phân đoạn với các buổi họp

sơ kết và cải tiến

Tuy nhiên, chỉ tăng tần suất phản hồi và giao tiếp là không đủ để loại bỏ các vấn đề về truyền thông Chu kỳ thanh-tra-và-thích-nghi làm việc tốt chỉ khi các thành viên trong nhóm thể hiện những hành vi quan trọng sau:

 Tôn trọng giá trị của mỗi cá nhân

 Trung thực trong truyền thông

 Minh bạch về dữ liệu, hoạt động, và quyết định

 Tin tưởng vào sự hỗ trợ của mỗi cá nhân với nhóm

 Cam kết với nhóm và các mục tiêu của nhóm

Để thúc đẩy các hành vi này, nhà quản lý linh hoạt phải cung cấp một môi trường hỗ trợ, các nhà huấn luyện phải tạo điều kiện thuận lợi, và các thành

viên của nhóm phải thể hiện chúng Chỉ khi đó nhóm mới có thể phát huy được hết tiềm năng của mình

Đạt tới các hành vi đó khó khăn hơn rất nhiều so với việc hình thành chúng Hầu hết các nhóm tránh né sự thật, sự minh bạch, và tin tưởng vào các chuẩn mực văn hóa hoặc có những kinh nghiệm tiêu cực từ các xung đột xuất phát từ truyền thông trung thực trước đây Để chống lại những khuynh hướng này, ban lãnh đạo và thành viên nhóm phải tạo điều kiện cho những xung đột tích cực Làm như vậy không chỉ giúp tạo ra hành vi sinh lợi mà còn đem lại các lợi ích khác:

 Cải tiến quy trình phụ thuộc vào nhóm trong việc tạo ra danh sách các trở ngại hoặc vấn đề trong tổ chức, đối mặt với chúng một cách trung thực, và sau đó loại bỏ chúng một cách có hệ thống tùy theo độ ưu tiên

 Đổi mới chỉ xảy ra với việc tự do trao đổi các ý tưởng mâu thuẫn lẫn nhau, một hiện tượng được nghiên cứu và viết thành tài liệu bởi Takeuchi và Nonaka, những người cha đỡ đầu của Scrum

 Việc hướng các nhóm tới mục tiêu chung đòi hỏi nhóm phải đối mặt

và giải quyết các vấn đề về xung đột

 Cam kết làm việc cùng nhau sẽ xảy ra chỉ khi mọi người đồng ý với mục tiêu chung và sau đó đấu tranh cho sự tiến bộ của bản thân cũng như nhóm

Ý cuối cùng ở trên nói về cam kết là đặc biệt quan trọng Đó là khi mà các

cá nhân và các nhóm được cam kết mà họ cảm thấy có trách nhiệm với việc cung cấp các giá trị cao, đó là điểm mấu chốt đối với các nhóm phát triển phần mềm Các phương pháp linh hoạt tạo điều kiện cho việc cam kết bằng cách khuyến khích các nhóm đưa ra một danh sách các công việc được ưu tiên hóa,

để họ tự quản lý công việc của mình, và tập trung vào cải tiến về cách thực hiện các công việc đó Thực hành là nền tảng của tự-tổ-chức (self-organization), đó là động lực để đạt được kết quả trong một nhóm Agile

Để tạo ra các nhóm có hiệu suất cao, các phương pháp linh hoạt coi trọng

cá nhân và sự tương tác hơn là quy trình và công cụ Thực tế cho thấy rằng, tất

cả các phương pháp linh hoạt tìm kiếm sự gia tăng trong truyền thông và cộng tác thông qua việc kiểm tra thường xuyên các chu trình thanh-tra-và-thích-nghi Tuy nhiên, các chu trình đó chỉ thực sự làm việc tốt khi mà các nhà lãnh đạo Agile khuyến khích các cuộc xung đột tích cực, thứ cần thiết để xây dựng một nền tảng vững chắc cho sự trung thực, tính minh bạch, lòng tin, sự tôn trọng, và cam kết từ các nhóm Agile của họ

I.3.2 Phần mềm Chạy tốt hơn là Tài liệu đầy đủ

Phần mềm chạy tốt là một trong những khác biệt lớn mà phát triển linh hoạt mang lại Tất cả các phương pháp linh hoạt thể hiện Tuyên ngôn Agile bằng cách nhấn mạnh việc cung cấp một phần nhỏ của phần mềm chạy tốt tới khách hàng sau một khoảng thời gian nhất định

Tất cả các nhóm Agile phải xác lập những gì họ muốn nói là “phần mềm chạy tốt”, cái thường được biết như là định nghĩa hoàn thành Ở mức độ cao, một phần của chức năng hoàn thành chỉ khi các tính năng của chúng vượt qua tất cả các kiểm thử và có thể được vận hành bởi người dùng cuối Ở mức thấp nhất, các nhóm phải vượt qua được kiểm thử đơn vị (unit test) và kiểm thử hệ thống Các nhóm tốt nhất còn bao gồm việc kiểm thử tích hợp, kiểm thử hiệu năng, và kiểm thử chấp nhận của khách hàng trong định nghĩa hoàn thành đối với một phần chức năng Thông qua nguồn dữ liệu phong phú từ các dự án, một công ty CMMI cấp độ 5 cho thấy việc xác định kiểm thử chấp nhận cùng với các tính năng, triển khai một loạt các tính năng và theo độ ưu tiên, ngay lập tức chạy các kiểm thử chấp nhận với mỗi tính năng, và sửa bất cứ một lỗi nào

có độ ưu tiên cao nhất sẽ tăng gấp đôi tốc độ sản xuất và giảm các sai sót đến 40% Điều này có được từ một công ty có tỷ lệ sai sót thấp nhất thế giới

Tuyên ngôn Agile khuyến nghị các nhóm cung cấp phần mềm chạy tốt sau một khoảng thời gian nhất định Đồng thuận với định nghĩa hoàn thành là một trong những cách thực tế để nhóm Agile mang lại hiệu suất và chất lượng cao, cái cần thiết để hoàn thành mục tiêu này

I.3.3 Cộng tác với khách hàng hơn là thương thảo hợp đồng

Trong hai thập kỷ qua, tỉ lệ thành công của các dự án tăng hơn hai lần trên toàn thế giới Điều này được cho là vì các dự án nhỏ hơn và mức độ chuyển giao thường xuyên đã cho phép khách hàng cung cấp các thông tin phản hồi về phần mềm hoạt động một cách đều đặn hơn Các tác giả của bản Tuyên ngôn

đã làm sáng tỏ điều này khi họ nhấn mạnh rằng việc để khách hàng tham gia vào quá trình phát triển phần mềm là hết sức cần thiết để dẫn tới thành công Các phương pháp phát triển linh hoạt đã thúc đẩy giá trị này bằng cách đưa vào một đồng minh tích cực của khách hàng làm việc sát cánh với đội phát triển Lấy một ví dụ, một nhóm Scrum đầu tiên có hàng ngàn khách hàng Sẽ là không khả thi nếu cho phép tất cả khách hàng tham gia vào quá trình phát triển sản phẩm, vì vậy họ chọn ra một vị đại sứ của khách hàng, được gọi là Product Owner (chủ sản phẩm), để đại diện cho không chỉ tất cả khách hàng trong trường hợp này mà còn bao gồm cả quản lý, dịch vụ khách hàng, và các bên

liên quan khác Chủ sản phẩm có trách nhiệm cập nhật danh sách yêu cầu về sản phẩm sau mỗi bốn tuần thời điểm mà nhóm Scrum phát hành phiên bản sản phẩm chạy tốt, có tính đến yếu tố thực tế cùng phản hồi của khách hàng và các bên liên quan Điều này cho phép khách hàng có thể giúp định hình sản phẩm phần mềm đang được tạo ra

Một nhóm XP đầu tiên đã bắt đầu với một dự án CNTT nội bộ Họ có thể

có sẵn người sử dụng đầu cuối của công ty trong nhóm làm việc với họ hàng ngày Khoảng 10% thời gian, các tư vấn viên và nhóm nội bộ có thể tìm được một người dùng cuối có thể làm việc với nhóm từng ngày 90% thời gian còn lại, họ phải cử ra người đại diện cho khách hàng Người này, được nhóm XP gọi là Customer (khách hàng), làm việc trực tiếp với người dùng cuối để cung cấp một danh sách các tính năng rõ ràng cùng độ ưu tiên cho phép đội phát triển có thể thực hiện

Cộng tác với khách hàng (hoặc đại diện của khách hàng) trên cơ sở hàng ngày là một trong những lý do lý giải tại sao các dữ liệu trong ngành công nghiệp cho thấy rằng các dự án linh hoạt có tỉ lệ thành công cao hơn gấp đôi so với các dự án truyền thống tính trung bình trên toàn thế giới Các phương pháp phát triển linh hoạt đã nhận ra điều đó, và do vậy, chúng đã tạo ra một vị trí đặc biệt trong đội hình phát triển để dành riêng cho vị khách hàng đại diện này

I.3.4 Phản hồi với thay đổi hơn là bám sát kế hoạch

Phản hồi với thay đổi là điều cần thiết cho việc tạo ra một sản phẩm làm hài lòng khách hàng cũng như mang lại những giá trị kinh doanh Dữ liệu ngành công nghiệp cho thấy hơn 60% các yêu cầu về sản phẩm hay dự án bị thay đổi suốt quá trình phát triển phần mềm Ngay cả khi các dự án truyền thống kết thúc đúng thời gian, đúng kinh phí, với tất cả các tính năng theo kế hoạch, nhưng khách hàng thường không hài lòng vì những gì họ thấy không thật sự đúng như những gì họ muốn Luật Humphrey nói rằng khách hàng không bao giờ biết những gì họ muốn cho đến khi họ thấy phần mềm hoạt động Nếu khách hàng không nhìn thấy phần mềm hoạt động cho đến khi kết thúc dự án, sẽ là quá muộn cho việc kết hợp các thông tin phản hồi của họ ở thời điểm này Các phương pháp phát triển linh hoạt tìm kiếm sự phản hồi của khách hàng trong suốt dự án để có thể kết hợp thông tin phản hồi và thông tin mới ngay khi sản phẩm đang được phát triển

Tất cả các phương pháp phát triển linh hoạt đều được tích hợp sẵn những tiến trình thay đổi các kế hoạch trong một khoảng thời gian đều đặn dựa trên những thông tin phản hồi từ phía khách hàng cũng như bên đại diện của khách hàng Các kế hoạch được thiết kế để sao cho luôn cung cấp giá trị kinh doanh

cao nhất trước hết Bởi vì 80% giá trị nằm trong 20% các tính năng, một dự án phát triển linh hoạt chạy tốt có xu hướng kết thúc sớm, trong khi hầu hết các dự

án truyền thống thường kết thúc trễ Kết quả là, khách hàng thì vui vẻ hơn, và các nhà phát triển thì thích thú với công việc của họ hơn Các phương pháp phát triển linh hoạt dựa trên những hiểu biết đó, để thành công hơn chúng phải

có kế hoạch để thay đổi Đó là lý do tại sao chúng thiết lập các quy trình, chẳng hạn như Sơ kết và Cải tiến, được thiết kế đặc biệt để thay đổi các ưu tiên thường xuyên dựa trên thông tin phản hồi của khách hàng và giá trị kinh doanh

I.3.5 Agile là chiếc ô – Các phương pháp dưới chiếc ô này

Phát triển linh hoạt bản thân nó không phải là một phương pháp Nó là một thuật ngữ chung mô tả rất nhiều các phương pháp linh hoạt Tại thời điểm ký kết Tuyên ngôn Agile năm 2001, những phương pháp này bao gồm: Scrum,

XP, Crystal, FDD, và DSDM Kể từ thời điểm đó, Lean cũng đã nổi lên như là một phương pháp linh hoạt có giá trị do vậy cũng được đưa vào trong chiếc ô của các phương pháp Agile trong hình minh họa dưới đây

Agile là chiếc ô [9]

Mỗi phương pháp phát triển linh hoạt có một cách tiếp cận hơi khác nhau

để thực hiện các giá trị cốt lõi trong tuyên ngôn Agile, cũng giống như các ngôn ngữ máy tính có các biểu hiện tính năng cốt lõi trong lập trình hướng đối tượng theo những cách khác nhau Một cuộc khảo sát gần đây cho thấy rằng, khoảng 50% học viên theo học phương pháp phát triển linh hoạt nói rằng đội của họ đang làm Scrum, 20% khác nói rằng họ đang làm Scrum với các thành phần của XP Khoảng 12% nói rằng họ chỉ áp dụng XP Do có hơn 80% áp dụng phát triển linh hoạt trên toàn thế giới là sử dụng Scrum và XP, nên bản MSF cho phát triển phần mềm linh hoạt phiên bản 5.0 tập trung vào quy trình cốt lõi và thực tiễn áp dụng của Scrum và XP

Scrum là một khung làm việc (framework) cho các quy trình phát triển linh hoạt Nó không bao gồm các vấn đề thực hành, kỹ thuật cụ thể Ngược lại,

XP lại tập trung vào các kỹ thuật thực hành cụ thể nhưng không có một bộ khung làm việc tổng thể cho quá trình phát triển Điều đó không có nghĩa rằng Scrum khuyên bạn không nên áp dụng các phương pháp thực hành cụ thể hay

là XP thì không có quy trình Ví dụ, ban đầu Scrum áp dụng tất cả các phương pháp thực hành mà bây giờ được biết đến như là XP Tuy nhiên, khung làm việc Scrum cho việc phát triển phần mềm được thiết kế để có được một nhóm nghiên cứu bắt đầu trong hai ba ngày, trong khi thực hành kỹ thuật phải mất nhiều tháng để thực hiện Vì vậy, nó để lại câu hỏi khi nào (hay không) để thực hiện các thực hành cụ thể đối với mỗi đội Hai đồng tác giả của Scrum là Jeff Sutherland và Ken Schwaber khuyến nghị rằng Nhóm Scrum bắt đầu ngay lập tức và tạo ra danh sách các trở ngại và kế hoạch cải tiến quy trình Khi việc thực hành về kỹ thuật được xác định là trở ngại, nhóm nên xem xét các phương pháp thực hành của XP như là một cách để cải tiến Các nhóm tốt nhất sử dụng Scrum bổ sung với thực hành XP Scrum giúp XP về mặt quy mô, XP giúp Scrum làm việc tốt hơn

Bảng sau cho thấy những thuật ngữ quan trọng tương ứng giữa Scrum và XP:

Chủ sản phẩm (Product Owner) Khách hàng (Customer)

Họp Kế hoạch Sprint (Sprint

Planning)

Trò chơi lập kế hoạch (Planning Game)

CHƯƠNG II HTTT BỆNH VIỆN VÀ BỆNH ÁN ĐIỆN TỬ

Phần này sẽ đi vào đề xuất kiến trúc cũng như giải pháp và thực hiện phân tích một HTTT bệnh viện điển hình, đây là hệ thống phần mềm mà tác giả đã trải qua quá trình xây dựng hệ thống tương đương cùng với việc tham khảo các sản phẩm tương đương trên thị trường, cũng như hợp tác với các chuyên gia nhiều năm kinh nghiệm trong xây dựng, triển khai và quản lý phần mềm tổng thể ERP ở trong nước cũng như nước ngoài; thông qua đó đúc rút được nhiều kinh nghiệm cả thành công và thất bại, để đề xuất được một sản phẩm hay chính xác hơn là một giải pháp toàn diện, giúp cho các bệnh viện áp dụng được Bệnh án Điện tử vào tác nghiệp hàng ngày để nâng cao năng lực quản trị của

cơ sở cũng như liên thông với các đơn vị trong ngành

Trước khi đi vào phân tích kiến trúc và đưa ra mô hình phần mềm cho tới

hạ tầng CNTT cho một bệnh viện quy mô lớn, cho nhiều chi nhánh, kết nối với nhau và sẵn sàng để kết nối vào hệ thống CNTT chung của Bộ Y tế; phần 1 của chương này sẽ đi vào phân tích hiện trạng ứng dụng CNTT trong các bệnh viện nằm trong bối cảnh tổng thể của cả ngành y tế cũng như cấp cao nhất là Bộ Y tế; theo đó giúp người đọc hình dung được bối cảnh cũng như vấn đề ở thời điểm thực hiện luận văn, cũng như phương pháp tiếp cận của tác giả trong việc giải quyết các vấn đề hiện trạng này

II.1 HIỆN TRẠNG ỨNG DỤNG CNTT TRONG CÁC BỆNH VIỆN

II.1.1 Cơ cấu hoạt động ngành

Bộ Y tế thực hiện chức năng quản lý nhà nước về chăm sóc và bảo vệ sức khỏe nhân dân bao gồm các lĩnh vực y tế dự phòng, khám bệnh, chữa bệnh, phục hồi chức năng, giám định, pháp y, pháp y tâm thần, y dược cổ truyền, dược, mỹ phẩm, an toàn vệ sinh thực phẩm, trang thiết bị y tế, bảo hiểm y tế, dân số - kế hoạch hóa gia đình, sức khỏe sinh sản, quản lý nhà nước các dịch

vụ công trong lĩnh vực thuộc phạm vi quản lý của Bộ

Để thực hiện các chức năng này, hệ thống y tế đã được tổ chức gồm theo tuyến: Trung ương - tỉnh - huyện - xã, phường, bao gồm trên 13 nghìn cơ sở y

tế công lập, 11.141 trạm y tế xã, phường [1] Hệ thống tổ chức ngành y tế được chia theo:

- Hệ thống quản lý hành chính nhà nước: Bộ Y tế, các Sở Y tế (cấp tỉnh) và các Phòng y tế huyện, quận

- Hệ điều trị: Gồm hơn 1062 bệnh viện, trong đó có 39 bệnh viện tuyến trung ương, 382 bệnh viện tuyến tỉnh, 561 bệnh viện huyện, gần 48 bệnh viện các ngành, 132 bệnh viện tư nhân và hàng nghìn phòng khám tư nhân

- Hệ thống y tế dự phòng: Có gần 10 Viện nghiên cứu trung ương, trên

100 trung tâm y tế dự phòng tuyến tỉnh và trên 700 trung tâm y tế tuyến huyện và 11.141 trạm y tế xã, phường

- Hệ thống đào tạo và nghiên cứu khoa học: 30 cơ sở nghiên cứu, 20 trường đại học, trên 30 trường cao đẳng và trên gần 100 cơ sở đào tạo trung học và dạy nghề y tế

-Hệ thống dược phẩm và trang thiết bị y tế gồm trên 5.000 công ty, xí nghiệp và nhà thuốc, bên cạnh đó có trên 10.000 nhà thuốc, cơ sở kinh doanh trang thiết bị y tế tư nhân

Tổng số cán bộ đang hoạt động trong ngành y tế công lập gồm hơn 300 nghìn người với trên 60.000 cán bộ có trình độ sau đại học và đại học, gần 200 nghìn cán bộ y tế có trình độ trung cấp [2]

II.1.2 Hiện trạng và các tồn tại

II.1.2.1 Về môi trường pháp lý và cơ sở dữ liệu dùng chung

Ngành Y tế đến nay vẫn chưa xây dựng được một môi trường pháp lý phù hợp cho việc đẩy mạnh các ứng dụng công nghệ thông tin: Các tiêu chuẩn trao đổi thông tin chưa được ban hành, các bộ danh mục chuẩn chuyên ngành chưa được hoàn thiện, các bộ qui tắc chưa được thống nhất Đây cũng là một lý do cho tình trạng ứng dụng rời rạc, phân tán tại các cơ sở y tế khác nhau, ảnh hưởng đến việc xây dựng cơ sở dữ liệu dùng chung trong ngành y tế, kết xuất

dữ liệu hệ thống thông tin bệnh viện phục vụ thanh toán bảo hiểm y tế, liên thông dữ liệu

Danh mục bệnh (từ điển đỏ) được Bộ Y tế ban hành từ năm 2002 dựa trên danh mục chuẩn quốc tế ICD10 Đến nay danh mục này vẫn còn nhiều bất cập như chưa được chuẩn hóa tên gọi trong toàn quốc, một số thông tin đã lạc hậu

và cần được cập nhật cho phù hợp hơn

Danh mục phẫu thuật, thủ thuật, danh mục thuốc, hóa chất, vắc xin chưa đầy đủ và chưa được mã hóa phục vụ cho việc quản lý và tin học hóa các quy trình, ứng dụng nghiệp vụ trong ngành

Danh mục trang thiết bị y tế và danh mục các cơ sở khám chữa bệnh chưa được chuẩn hóa và mã hóa Vụ Bảo hiểm y tế (Bộ Y tế) đã tổ chức một số buổi

hội thảo nhằm mục đích xây dựng danh mục các cơ sở khám chữa bệnh, nhưng danh mục này vẫn chưa được hoàn thiện và chủ yếu để phục vụ mục đích đăng

ký khám lần đầu cho người có bảo hiểm y tế

Tiêu chuẩn kiến trúc y tế điện tử và chuẩn trao đổi thông tin giữa các cơ

sở khám chữa bệnh chưa được xây dựng, do vậy công việc xây dựng bệnh án điện tử và tích hợp các hệ thống đang sử dụng tại các cơ sở khám chữa bệnh khác nhau chưa thể thực hiện Điều này gây trở ngại cho việc tin học hóa công tác khám chữa bệnh và xây dựng cơ sở dữ liệu bệnh án điện tử liên thông trong toàn quốc

Các tiêu chuẩn về mã định danh người bệnh chưa có gây cản trở cho việc xây dựng cơ sở dữ liệu người bệnh trong toàn quốc Do chưa có mã định danh, rất khó để tạo cơ chế đồng nhất khi một người bệnh có hai hay nhiều hồ sơ bệnh án ở nhiều cơ sở khám chữa bệnh khác nhau

Cơ sở dữ liệu phục vụ công tác dân cư đã được Tổng cục Dân số và Kế hoạch hóa gia đình (TCDS và KHHGĐ) triển khai từ năm 1997 Hiện nay, TCDS và KHHGĐ đã thu thập và số hóa được cơ bản đầy đủ dữ liệu trên 90 triệu dân cư trên toàn quốc Dữ liệu này được lưu trữ tập trung và cập nhật định

kỳ theo tháng, quý và năm và được thu thập theo 10 tiêu chí chính cùng một số tiêu chí phụ liên quan đến dân số và kế hoạch hóa gia đình Khác với các dữ liệu dân cư thuộc quản lý của ngành tư pháp hay công an, dữ liệu dân cư do TCDS và KHHGĐ được quản lý theo thực tế số người sinh sống tại địa phương

và theo dõi theo biến động sinh, chết, kết, ly, đi, đến Cơ sở dữ liệu dân cư do TCDS và KHHGĐ quản lý khá đầy đủ và được cập nhật thường xuyên, có thể

sử dụng làm cơ sở dữ liệu nền tảng cho ngành y tế

Cơ quan bảo hiểm xã hội đang quản lý cơ sở dữ liệu người tham gia bảo hiểm y tế tại cấp tỉnh và triển khai xây dựng cơ sở dữ liệu quốc gia về đối tượng bảo hiểm y tế tại trung ương trong năm 2014 Từ 01/01/2014, trên mã thẻ bảo hiểm y tế đã được in mã vạch, tạo thuận lợi cho cơ sở khám chữa bệnh

và giảm đáng kể thời gian chờ làm thủ tục khám bệnh, chữa bệnh Tuy nhiên,

do chưa có mã định danh cho người tham gia bảo hiểm y tế nên việc theo dõi, quản lý quá trình tham gia và khám, chữa bệnh của người tham gia bảo hiểm y

tế gặp nhiều khó khăn Việc tổng hợp thông tin từ cấp cơ sở đến cấp quản lý được giao tiếp file điện tử kết hợp với giấy tờ, phải qua nhiều khâu trung giao nên dữ liệu cũng khó chính xác và kịp thời

Để đáp ứng được các yêu cầu về sự thống nhất các dữ liệu danh mục tham chiếu, việc đưa vào ứng dụng hệ thống cơ sở dữ liệu, các bộ mã dùng chung sẽ tăng cường tính hiệu quả trong việc thống nhất hệ thống danh mục và tạo ra sự

liên thông cần thiết trong việc trao đổi dữ liệu giữa các phần mềm ứng dụng trong các cơ sở khám chữa bệnh trên toàn quốc và kết nối thanh toán với Bảo hiểm Y tế

II.1.2.2 Về các ứng dựng công nghệ thông tin chuyên ngành

II.1.2.2.1 Ứng dụng công nghệ thông tin tại các cơ sở khám chữa bệnh

Hiện trạng việc ứng dụng CNTT trong các cơ sở khám chữa bệnh là rất đa dạng nhưng cũng rất rời rạc và không tập trung, chủ yếu dùng cho công việc tài chính, văn phòng, thống kê, báo cáo Hạ tầng CNTT tại đa số cơ sở khám chữa bệnh còn thiếu và đã cũ không đáp ứng được cho việc ứng dụng các phần mềm mới Hiện tại, các đơn vị trong ngành sử dụng các phần mềm đặc trưng cho ngành như:

- Phần mềm quản lý bệnh viện (chủ yếu quản lý về mặt chi phí) từ nhiều nhà cung cấp khác nhau

- Phần mềm thanh toán bảo hiểm y tế do Bảo hiểm xã hội cung cấp miễn phí

- Phần mềm báo cáo thống kê Medisoft 2003 của Bộ Y tế

- Phần mềm kế toán

- Phần ứng dụng: Quản lý nhân sự, quản lý công văn,

- Nhiều bệnh viện đang cùng một lúc sử dụng 5, 6 phần mềm khác nhau cho nhiều mục đích khác nhau

Mặc dù việc ứng dụng công nghệ thông tin tại một số cơ sở khám chữa bệnh đã mang lại một số kết quả nhất định, nhưng còn rất nhiều hạn chế:

- Chưa có phần mềm quản lý tổng thể thông tin bệnh viện, quản lý toàn diện bệnh nhân và hoạt động khám chữa bệnh theo quy trình khép kín, liên hoàn

- Không có sự kết nối, liên thông với nhau, dữ liệu không thống nhất, không chuẩn hóa

- Chưa có phần mềm phục vụ các ứng dụng kỹ thuật y tế chuyên sâu như: Quản lý bệnh án điện tử, quản lý chẩn đoán hình ảnh, quản lý phẫu thuật thủ thuật, toa thuốc điện tử, phân tích mô hình bệnh tật

- Chưa tạo một công cụ hỗ trợ hữu hiệu nhất gắn bó với người sử dụng, phục vụ đắc lực công việc chuyên môn hàng ngày

Khi việc ứng dụng phần mềm không thống nhất, thiếu đồng bộ và tổng thể thì ngoài hiệu quả khai thác vừa thấp còn tạo thêm gánh nặng cho nhân viên y

tế khi làm hai việc song song: Ghi chép sổ sách và nhập dữ liệu vào máy tính

II.1.2.2.2 Ứng dụng công nghệ thông tin trong bảo hiểm y tế

Hiện nay cơ quan Bảo hiểm y tế đang khai thác và cung cấp 2 phần mềm như sau:

- Phần mềm HMS:

+ Có một số chức năng hỗ trợ cho giám định thanh toán bảo hiểm y tế + Hỗ trợ việc cấu hình nguyên tắc thanh toán (do Bộ Y tế qui định) + Thực hiện theo hình thức Offline

- Phần mềm Viện phí 2.0:

+ Được sử dụng chủ yếu tại các bệnh viện tại các địa phương

+ Mục đích phục vụ bệnh viện trong công tác ghi nhận chi phí bảo hiểm y tế và hỗ trợ cho việc làm thanh quyết toán bảo hiểm y tế + Không phục vụ cho quá trình giám định bảo hiểm y tế

Công tác giám định của cơ quan Bảo hiểm xã hội thực hiện thủ công, trực tiếp trên hồ sơ bệnh án của bệnh viện do chưa ứng dụng được bệnh án điện tử Đến nay, chỉ một số bệnh viện sử dụng phần mềm thống kê khám chữa bệnh do

cơ quan Bảo hiểm xã hội cung cấp mới đáp ứng được yêu cầu trao đổi dữ liệu điện tử phục vụ một phần hoạt động giám định bảo hiểm y tế Để ứng dụng công nghệ thông tin đầy đủ vào quy trình giám định, cơ sở khám chữa bệnh và

cơ quan BHXH đều phải thỏa mãn các điều kiện tiên quyết: đối với cơ sở khám, chữa bệnh, toàn bộ quá trình tiếp nhận, khám và điều trị người bệnh phải được tin học hóa, ứng dụng đầy đủ mô hình y tế điện tử; Cơ quan Bảo hiểm

xã hội phải có phần mềm liên thông bệnh viện, xây dựng bộ quy tắc, từ điển giám định điện tử

Ngoài ra còn có vấn đề lạm dụng thẻ bảo hiểm y tế của bệnh nhân để nhận thuốc, hưởng dịch vụ không đúng quy định gây thất thoát lớn cho ngân sách nhà nước mà chưa có biện pháp ngăn chặn hữu hiệu

II.1.2.3 Về hạ tầng CNTT, mạng truyền dữ liệu và trung tâm dữ liệu

Tất cả các Vụ, Cục, Văn phòng Bộ, Tổng cục đã kết nối mạng nội bộ và kết nối internet tốc độ cao Tỷ lệ trung bình máy tính/CBCC: 100% (trừ khối hành chính - quản trị - bảo vệ)

Bộ Y tế đã có 100% các đơn vị trực thuộc có mạng LAN và kết nối internet tốc độ cao, bình quân mỗi mạng có trên 110 máy tính, 43% có hệ thống bảo mật, 53% có hệ thống backup dữ liệu;

Tại các tỉnh: 95,3% Văn phòng Sở có mạng LAN và kết nối được Internet tốc độ cao, 26% có hệ thống bảo mật và 24% có hệ thống lưu trữ dữ liệu;

Trong 280 bệnh viện địa phương được điều tra có 151 (52,9%) bệnh viện tỉnh có LAN và 81% kết nối được Internet tốc độ cao, 37,2% bệnh viện huyện

có mạng LAN và 65% kết nối internet;

Một số ít cơ sở y tế (chiếm 2%) có đường truyền riêng, trên 70% đơn vị

sử dụng đường truyền ADSL; 100% các trường Đại học, Cao đẳng Y - Dược

có mạng LAN, kết nối Internet và Website;

Có 16% Sở Y tế có địa chỉ website trên Internet, 27% đơn vị trực thuộc

Bộ Y tế có trang web, gần 80 đơn vị trực thuộc các sở y tế có Web site trên Internet [1]

Ngành y tế chưa xây dựng được mạng WAN kết nối Bộ Y tế với các Sở

Y tế, các cơ sở khám chữa bệnh, các Trung tâm, trạm y tế Điều này gây khó khăn cho việc trao đổi thông tin, liên thông dữ liệu, triển khai các dịch vụ như hội chẩn từ xa, telemedicine, hội nghị truyền hình

Ngành y tế cũng chưa có Trung tâm tích hợp dữ liệu quy mô quốc gia lưu trữ các CSDL danh mục dùng chung, CSDL quốc gia về người bệnh, CSDL quốc gia về bệnh án điện tử và các CSDL khác của ngành y tế

II.1.2.4 Về nguồn nhân lực về CNTT

Nhân lực công nghệ thông tin đã trở thành một loại hình lao động quan trọng trong ngành y tế Hầu hết các cơ sở y tế từ tuyến huyện trở lên đã có cán

bộ chuyên trách về công nghệ thông tin có trình độ từ trung cấp trở lên Bình quân mỗi Sở Y tế có 1,57 người và ở các đơn vị trực thuộc là 3,68 người Nhân lực CNTT chiếm khoảng 1% so tổng số nhân lực y tế từ huyện trở lên Hiện nay đã có 50% số Sở Y tế và 81% Cơ sở trực thuộc đã có chính sách phát triển nguồn nhân lực công nghệ thông tin cho đơn vị Tuy nhiên, chưa có chương trình công nghệ thông tin riêng đặc thù cho lĩnh vực y tế nên chưa có nhiều cán

bộ giỏi về chuyên CNTT y tế Số cán bộ chuyên môn trong ngành y tế từ tuyến tỉnh trở lên sử dụng được công nghệ thông tin cho công việc đạt trên 90% Nhìn chung nhân lực chuyên môn về CNTT trong ngành y tế hiện nay rất thiếu, mất cân đối, chưa chuyên sâu, khả năng tiếp nhận chuyển giao CNTT

còn nhiều hạn chế và đây được coi là điểm yếu rất cơ bản, những “nút thắt” cần sớm khắc phục

II.1.3 Các giải pháp đã triển khai và khó khăn vướng mắc

II.1.3.1 Các giải pháp đã triển khai

Bộ Y tế đã thành lập Cục Công nghệ thông tin trực thuộc Bộ theo Quyết định số 4048/QĐ-BYT ngày 22/10/2012 với mục đích đẩy mạnh ứng dụng công nghệ thông tin trong ngành Cục Công nghệ thông tin là đầu mối tổ chức thực hiện việc ứng dụng và phát triển công nghệ thông tin trong hoạt động của các cơ quan, đơn vị sự nghiệp thuộc Bộ Trong kế hoạch tổng thể ứng dụng và phát triển công nghệ thông tin của Bộ Y tế giai đoạn 2014-2015 và định hướng đến năm 2020, Bộ Y tế đã và đang xây dựng và thực hiện các nhóm dự án sau:

- Xây dựng các văn bản quy phạm pháp luật và văn bản hướng dẫn chuyên ngành về CNTT y tế;

- Xây dựng CSDL danh mục dùng chung cho khám chữa bệnh và bảo hiểm y tế;

- Xây dựng cơ sở dữ liệu y tế quốc gia (theo Quyết định 2360/QĐ-BYT);

- Xây dựng cơ sở dữ liệu quốc gia về bảo hiểm y tế (Nghị quyết của Quốc hội về Luật Bảo hiểm y tế);

- Kết nối mạng WAN ngành Y tế (theo Quyết định 2360/QĐ-BYT);

- Bệnh án điện tử và quản lý hệ thống khám chữa bệnh giai đoạn

2011-2014 (dự án trọng điểm theo quyết định số 1605/QĐ-TTg - đã bắt đầu triển khai);

- Thí điểm áp dụng thẻ bảo hiểm y tế điện tử trong quản lý bệnh nhân bảo hiểm y tế (đã có quyết định phê duyệt dự án của Bộ Y tế);

- Triển khai ứng dụng chữ ký số cho các đơn vị, cá nhân có thẩm quyền của các đơn vị trực thuộc Bộ (Quyết định số 436/QĐ-BYT ngày 7/2/2014);

- Xây dựng hệ thống kết nối giám định và thanh toán bảo hiểm y tế (Nghị quyết của Quốc hội- Kỳ họp thứ 6, Quốc hội XIII Hiện tại Bộ Y tế đang phối hợp với Koica – Hàn Quốc để xin kinh phí ODA không hoàn lại dự kiến: 15 triệu USD);

- Ứng dụng công nghệ thông tin trong đề án bệnh viện vệ tinh giai đoạn 2013- 2020;

- Ứng dụng công nghệ thông tin trong đề án xây dựng và phát triển mô hình phòng khám bác sĩ gia đình tại Việt Nam giai đoạn 2013-2020;

- Ứng dụng công nghệ thông tin trong đề án Phát triển y tế biển, đảo Việt Nam đến năm 2020;

- Ứng dụng công nghệ thông tin trong y tế cơ sở;

- Xây dựng hệ thống tích hợp thông tin báo cáo phục vụ công tác chỉ đạo, điều hành của lãnh đạo Bộ;

- Xây dựng hệ thống thông tin thống kê y tế;

- Hệ thống quản lý văn bản và điều hành cơ quan Bộ y tế (đang triển khai);

- Cấp phép nhập khẩu trang thiết bị y tế theo chương trình ASEAN một cửa (có đề án riêng - Đề án hải quan một cửa);

- Cấp phép nhập khẩu thuốc theo chương trình ASEAN một cửa (có đề

án riêng Đề án hải quan một cửa);

- Triển khai 07 dịch vụ công trực tuyến tối thiểu mức độ 3 (Quyết định 1605/QĐ-TTg);

- Kiện toàn hệ thống tổ chức trong các đơn vị sự nghiệp ngành y tế theo Quyết định 1191/QĐ-BYT;

- Tổ chức đào tạo liên tục về kiến thức tin học, ứng dụng CNTT cho cán

bộ trong ngành y tế (Đào tạo CNTT cho cán bộ lãnh đạo, Hệ thống thông tin bệnh viện, An toàn bảo mật thông tin….)

Ngoài các nhóm dự án trong kế hoạch ứng dụng CNTT trong ngành y tế

đã nêu trên, một số đơn vị trực thuộc Bộ cũng đang xây dựng một số dự án CNTT khác:

- Vụ Kế hoạch - Tài chính đang xây dựng kế hoạch chiến lược ứng dụng CNTT đến năm 2020, tầm nhìn 2030, kế hoạch do EC tài trợ;

- Vụ Kế hoạch - Tài chính cũng đang xây dựng hai đề án: Đề án định suất thanh toán BH ở tuyến xã, thí điểm ở các trạm y tế thuộc 04 tỉnh

và Đề án chi trả theo DRG (trường hợp bệnh), có sự tham gia của Bảo hiểm Xã hội Việt Nam;

- Cục Khám chữa bệnh, Bộ Y tế đang xây dựng đề án Bệnh án điện tử gắn với bảo hiển xã hội, liên quan đến hệ thống khám chữa bệnh và thanh quyết toán bảo hiểm y tế;

- Trong năm 2013, văn phòng Bộ đã triển khai 2 dự án Nâng cấp hệ thống email và Nâng cấp cổng thông tin điện tử của Bộ Y tế, các dự

án đã đi vào hoạt động;

II.1.3.2 Các khó khăn, vướng mắc

Mặc dù quyết tâm của Lãnh đạo ngành y tế trong việc thúc đẩy ứng dụng CNTT trong ngành là rất cao, nhưng thực trạng ứng dụng công nghệ thông tin trong y tế hiện nay được đánh giá còn ở mức thấp so với thế giới và trong khu vực Chỉ số ứng dụng công nghệ thông tin trong ngành y tế so với các lĩnh vực khác vẫn còn thấp Dưới đây, chúng tôi liệt kê ra một số khó khăn, vướng mắc trong triển khai các dự án ứng dụng CNTT rút ra từ những kinh nghiệm trong thời gian qua:

- Các dự án chưa được gắn kết với nhau trong một giải pháp tổng thể cho toàn ngành y tế, một số kế hoạch của một số đơn vị được xây dựng riêng lẻ, điều này có thể gây ra chồng chéo, trùng lặp, lãng phí

và gây khó khăn trong việc tích hợp, liên thông các hệ thống với nhau khi có nhu cầu

- Các dự án được triển khai chủ yếu dựa vào nguồn kinh phí từ vốn ngân sách nhà nước, nguồn kinh phí này có thể không đủ cho dự án hoặc không có khi dự án cần mở rộng hoặc có những nhu cầu phát sinh khác

- Theo kinh nghiệm, điều khó nhất trong triển khai không phải là thiết

bị hay ứng dụng, mà là chính sách, tiếp theo là con người, nhân lực, tri thức, thói quen sử dụng (ví dụ về thói quen lãnh đạo, thói quen tại bệnh viện…) Các dự án đã triển khai chưa chú trọng đến đào tạo, nâng cao nhận thức người dùng

- Một số dự án triển khai không thành công do nguồn nhân lực yếu và khả năng duy trì, hỗ trợ không tốt, đường truyền không đảm bảo, cơ chế duy trì hỗ trợ dự án không tốt

- Ngành y tế có đặc thù riêng là nhiều khi sản phẩm tốt nhưng điều kiện

áp dụng chưa tốt thì không dùng mà có thể lại chọn sản phẩm không tốt bằng nhưng phù hợp với điều kiện sử dụng

- Một số dự án do các đơn vị của Bộ Y tế chủ trì thực hiện khó thành công bởi vì các đơn vị này không chuyên về công nghệ thông tin và có khó khăn khi cần phối hợp với các đơn vị liên quan Khi dự án có nhiều đơn vị tham gia, ví dụ như xây dựng các danh mục dùng chung,

Bộ Y tế cần trực tiếp chủ trì, chỉ đạo quyết liệt hoặc một đơn vị bên

ngoài chủ trì và có cơ chế để thuê lại các chuyên gia về chuyên môn trong Bộ thực hiện dự án

II.1.4 Kết luận

Rất nhiều khó khăn, thách thức ngành y tế đang đối mặt có thể được giải quyết nhờ ứng dụng các công cụ công nghệ thông tin Tuy nhiên điều này đòi hỏi một hành lang pháp lý phù hợp, các bộ danh mục tiêu chuẩn, xem xét một cách tổng thể hết các khía cạnh nhu cầu khác nhau từ các đơn vị, tránh chồng chéo, trùng lặp và lãng phí Đồng thời, cần có sự chỉ đạo quyết liệt, phối hợp chặt chẽ, đồng bộ giữa Bộ Y tế và các đơn vị liên quan như Bảo hiểm xã hội Việt Nam, các doanh nghiệp để thiết kế, xây dựng tổng thể cơ sở hạ tầng, các phần mềm, cơ sở dữ liệu khám chữa bệnh thống nhất và liên thông trên phạm

vi toàn quốc

Trong thực tế thì dù đã có rất nhiều nỗ lực, nhưng rất nhiều các dự án triển khai ứng dụng CNTT cho các cơ sở y tế, đặc biệt là tại các Bệnh viện công đã không thành công, hoặc chính xác hơn là thất bại, để lại hệ lụy và hậu quả lâu dài cho đơn vị ứng dụng cũng như nhà cung cấp; gây mất niềm tin ở người sử dụng cũng như tiếng xấu về HTTT Bệnh viện ở trong ngành Ngoài ra rào cản về chi phí để áp dụng là rất lớn so với ngân sách đầu tư nói chung của Bệnh viện (còn ngân sách CNTT thì hầu như rất nhỏ hoặc không có), trong khi

đó chi phí này thực tế để trang bị hệ thống phần mềm hoàn chỉnh là rất nhỏ so với mặt bằng chung (trang bị HTTT tổng thể cho đơn vị hàng nghìn người dùng)

Vậy để giải quyết được bài toán này, trong yêu cầu cơ bản nhất về một HTTT tổng thể ở cấp cơ sở để dần tiến tới HTTT tổng thể toàn quốc, thì Việt Nam cần phải tìm ra một con đường đi phù hợp hơn

II.2 BỆNH ÁN ĐIỆN TỬ VÀ HTTT BỆNH VIỆN

Phần này giới thiệu thông tin cơ bản và cấu trúc dữ liệu của Bệnh án điện

tử (BADT), theo đó để định hình được HTTT Bệnh viện sẽ có vai trò cũng như

vị trí như thế nào trong quá trình quản lý BADT trong bệnh viện

II.2.1 Cấu trúc Bệnh án điện tử

Một hồ sơ điện tử y tế (EHR), hoặc hồ sơ y tế điện tử (EMR), đề cập đến một tập hợp dữ liệu có hệ thống về bệnh nhân và thông tin sức khỏe được lưu trữ dưới dạng dữ liệu số hóa trong hệ thống máy tính Những hồ sơ này có thể được chia sẻ giữa các cơ sở y tế khác nhau thông qua kết nối mạng, hoặc được chia sẻ giữa các hệ thống phần mềm nội bộ trong bệnh viện BADT có thể bao gồm một loạt các dữ liệu, bao gồm cả nhân khẩu học, quá trình khám chữa

bệnh, thuốc và dị ứng, lịch sử tiêm chủng, kết quả xét nghiệm, hình ảnh X quang, các dấu hiệu sinh tồn, các thống kê cá nhân như tuổi tác và trọng lượng, cũng như thông tin thanh toán trong các quá trình khám chữa bệnh này [10] HTTT quản lý BADT được thiết kế để lưu trữ dữ liệu một cách chính xác

và để nắm bắt tình trạng của bệnh nhân trong suốt vòng đời khám chữa bệnh cũng như theo dõi tình trạng sức khỏe liên tục của bệnh nhân Nó giúp loại bỏ việc phải lưu trữ Hồ sơ bệnh án (HSBA) dưới dạng giấy tờ và phải bảo quản trong kho; theo đó hỗ trợ trong việc đảm bảo dữ liệu chính xác và dễ đọc Do được lưu trữ dưới dạng số hóa, chính vì vậy lợi ích thấy được ngay về việc khai thác số liệu như: Luân chuyển và tra cứu HSBA giữa các cơ sở khám chữa bệnh được dễ dàng, công tác nghiên cứu, thống kê/khai thác số liệu trong HSBA giúp cho nghiên cứu khoa học về khám chữa bệnh của các chuyên gia y

tế được thực hiện dễ dàng

BADT chính là một dạng lưu trữ điện tử của HSBA, theo quy định của Bộ

Y tế thì BADT phải lưu trữ nguyên trạng cũng như đầy đủ các thông tin như trên HSBA dạng giấy Như vậy trong toàn bộ quy trình KCB của bệnh nhân ở CSYT có những thông tin gì cần được ghi nhận vào HSBA thì đều phải được phản ánh/số hóa ở trong BADT dưới một định dạng số hóa; những định dạng này thường được quy ước riêng theo từng phần mềm, từng bệnh viện khác nhau, hoặc áp dụng chuẩn toàn cầu là HL7 để hỗ trợ cho việc trao đổi BADT trên phạm vi toàn cầu sau này Cho dù HSBA lưu trữ dưới dạng gì, định dạng gì: Giấy tờ, hay số hóa, chuẩn HL7 hay chuẩn riêng thì HSBA đều phải đạt được những tiêu chí như sau:

- Đầy đủ thông tin hành chính về bệnh nhân: Ghi nhận ở quá trình tiếp nhận bệnh nhân, nếu là BN BHYT thì phải có bằng chứng/thông tin về thẻ BHYT cũng như CQ BHYT thanh toán cho bệnh nhân (có thể một phần hay từng phần)

- Đầy đủ thông tin về quá trình khám chữa bệnh, bao gồm các thông tin tối thiểu như:

o Tư vấn bệnh

o Quá trình khám bệnh

o Tường trình tiểu phẫu/thủ thuật

o Kết quả xét nghiệm

o Hình ảnh chụp & kết quả chẩn đoán

o Các thông tin & kết luận cận lâm sàng khác

- Đầy đủ các bằng chứng pháp lý cho những tác nhân tham gia vào quá trình KCB của bệnh nhân: bao gồm bằng chứng về các y bác sĩ tham gia chẩn đoán, điều trị và chăm sóc cho bệnh nhân, bằng chứng về chính bệnh nhân và/hoặc người nhà bệnh nhân khi quyết định theo một phương

án điều trị nào đấy; tất cả các tác nhân này phải có bằng chứng xác thực cho bản thân khi tham gia quá trình này Thông thường thì dùng chính chữ ký tay vào giấy tờ liên quan (tờ chỉ định của bác sĩ, cam kết phẫu thuật của người nhà bệnh nhân, ), các giấy tờ này có thể được viết tay từ mẫu quy định của CQ y tế hoặc in ra từ phần mềm (sau khi đã được lưu trữ dưới dạng điện tử) để ký và lưu kho để làm căn cứ pháp lý sau này Bằng chứng phổ biến hiện tại chính là chữ ký (tươi) vào giấy tờ của các bên tham gia; Chữ ký số mới được BYT khuyến khích triển khai; trong tương lai ngắn tới đây, thì chữ ký số sẽ trở thành cơ sở pháp lý quan trọng, tiện dụng, an toàn và bảo mật để thay thế chữ ký tươi, đây cũng đảm bảo việc có thể luân chuyển được không những thông tin HSBA mà còn cả cơ sở pháp lý của HSBA đấy

II.2.2 HTTT Bệnh viện quản lý BADT

Đối với các HTTT Bệnh viện thì chức năng cơ bản nhất là đáp ứng được nhu cầu quản lý quá trình KCB của bệnh nhân của bệnh viện, phần mềm phải đảm bảo lưu vết được quá trình KCB cho bệnh nhân từ lúc bắt đầu tiếp đón và

tư vấn bệnh cho bệnh nhân, cho tới khi kết thúc quá trình điều trị/khám bệnh ở tại bệnh viện, quá trình này kết thúc bởi các lý do cơ bản như: khỏi bệnh cho

về, chuyển tuyến dưới/tuyến trên, hoặc bệnh nhân tự ý bỏ về

Các thông tin ghi nhận vào phần mềm, các chức năng hỗ trợ bởi phần mềm cho quá trình KCB này thì tùy theo từng phần mềm hay tùy theo từng bệnh viện yêu cầu mà sẽ ghi nhận thông tin rất cơ bản, cho tới thông tin đầy đủ

nhất, hoàn toàn không có quy định bắt buộc nào về những thông tin này Phần mềm HTTT bệnh viện đang có mặt trên thị trường thì hầu hết chỉ hỗ trợ ghi nhận thông tin, và đảm bảo nếu đã ghi nhận đủ thông tin thì những thông tin này có thể được ở dạng số hóa để bệnh viện có thể khai thác về sau cho 2 nhu cầu cơ bản nhất về CNTT cho các Bệnh viện là: công tác thống kê hỗ trợ quản

lý và tổng hợp để ra các báo cáo về chi phí nộp cho CQ BHYT và báo cáo chuyên môn bắt buộc để nộp cho SYT/BYT Còn những yếu tố pháp lý thì hầu như các phần mềm hiện hành đều không đáp ứng được vì thông tin ghi nhận không đầy đủ được như yêu cầu của HSBA chuẩn (như đã nêu ở phần trước),

và những nội dung đã ghi nhận thì vẫn phải cần in ra để ký và lưu trữ làm bằng chứng pháp lý, còn thông tin số hóa thì hoàn toàn chỉ có giá trị tham khảo, thông tin HSBA lưu trữ dạng giấy tờ vẫn là nguồn gốc có giá trị duy nhất

Để HTTT Bệnh viện đạt đủ điều kiện là một hệ thống quản lý BADT để trang bị cho Bệnh viện thành Bệnh viện điện tử thì cần có các yêu cầu như sau:

- Ghi nhận đầy đủ toàn diện các thông tin HSBA, tất cả các thông tin nào tìm thấy ở HSBA thông thường thì cũng phải tìm được thông tin tương ứng trong CSDL số hóa HSBA này

- Các định dạng số hóa để lưu trữ HSBA dạng điện tử - hay BADT – là tùy thuộc vào giải pháp của phần mềm hoặc yêu cầu khai thác số liệu sau này của BV; điều này không bắt buộc đối với phần mềm, nhưng phải đảm bảo khi cần lấy các thông tin tương ứng như tra cứu HSBA giấy thì phần mềm phải đáp ứng được

- Các BADT này phải dễ dàng để có thể xuất ra (export) để có thể mang sang nhập (import) vào hệ thống khác theo nhiều hình thức có thể là tích hợp trực tiếp/tự động, hoặc nhập vào thủ công, hay chỉ đơn giản để Y bác sĩ ở đơn vị khác có thể mở tệp ra xem ở máy tính được Chuẩn khuyến nghị là chuẩn HL7 để đảm bảo việc tương thích HSBA cấp độ toàn cầu

- Và một điều kiện cuối cùng rất khó khăn đó là đảm bảo tính pháp lý một cách toàn diện để thay thế HSBA ký tay, việc áp dụng chữ ký số là giải pháp duy nhất, chính vì vậy việc khó khăn nằm ở cả 2 điểm: phần mềm phải đáp ứng đủ tính năng 100% như HSBA và việc ký điện tử phải thực hiện song song, trực tiếp trong quá trình nhập liệu tác nghiệp của bất kỳ tác nhân nào tham gia vào quá trình khám chữa bệnh này

Do yêu cầu cao về HTTT Bệnh viện quản lý BADT như vậy, nên việc đưa vào áp dụng trong thực tế đã gặp rất nhiều khó khăn bởi vì một số lý do sau: