Kinh tế kỹ thuật phần mềm trong y tế

Vì sao điều này quan trọng trong kinh tế học sức khỏe

Mọi tổ chức y tế hiện đại, dù thừa nhận hay không, đều là một đơn vị vận hành phần mềm. Hồ sơ bệnh nhân, kê đơn, lập lịch, kết quả xét nghiệm, hồ sơ thanh toán và giám sát dân cư đều chạy trên mã — mua từ nhà cung cấp, xây nội bộ, thừa hưởng từ người tiền nhiệm, hoặc chắp vá từ cả ba. Số tiền liên quan lớn và lặp lại: các chương trình hồ sơ sức khỏe điện tử quốc gia đã tiêu tốn hàng tỷ đô la công quỹ, và chi phí vận hành phần mềm y tế — bảo trì, tích hợp, nâng cấp, bảo mật — thường lấn át mức giá xuất hiện trong luận chứng kinh doanh ban đầu. Vậy mà phần lớn đào tạo kinh tế y tế không nói gì về cách phần mềm hành xử như một tài sản kinh tế, và phần lớn đào tạo kỹ thuật phần mềm không nói gì về chi phí cơ hội trong một hệ thống cũng phải mua điều dưỡng và thuốc.

Khoảng trống này quan trọng vì phần mềm thất bại về kinh tế theo những cách đặc trưng mà phản xạ mua sắm thông thường không bắt được. Một hệ thống được mua dựa trên giá mua và các tính năng trình diễn; gánh nặng tích hợp, di chuyển dữ liệu và bảo trì đến sau, đối với những ngân sách chưa bao giờ được tham vấn. Một quan hệ nhà cung cấp cứng lại thành sự phụ thuộc, nên mỗi lần gia hạn được thương lượng từ thế yếu. Những lối tắt thực hiện dưới áp lực thời hạn tích tụ vô hình cho đến khi hệ thống vận hành bệnh viện không còn có thể thay đổi một cách an toàn — lúc đó tổ chức đối mặt với hóa đơn hiện đại hóa chưa bao giờ được lên kế hoạch và không thể hoãn, vì phần mềm nay mang rủi ro lâm sàng. Lịch sử của các chương trình CNTT y tế lớn, gồm Chương trình Quốc gia về CNTT của Anh (bị tháo dỡ năm 2011 sau chi phí ước tính khoảng 10 tỷ bảng), là lịch sử của những động lực này ở quy mô quốc gia.

Với một giám đốc, rủi ro có ba phần. Thứ nhất, tiền: phần mềm là một cam kết trọn vòng đời, và phương án rẻ lúc mua thường là phương án đắt trong một thập kỷ. Thứ hai, an toàn: trong bối cảnh lâm sàng một sự cố ngừng hoạt động, một lỗi dữ liệu, hay một hệ thống không bảo trì được không phải là bất tiện mà là hiểm họa, với chi phí rơi vào Chủ đề 3.11 — Kinh tế chất lượng và an toàn. Thứ ba, chủ quyền: các lựa chọn giữa xây và mua, giữa hệ thống độc quyền và mở, và giữa giao diện chuẩn và đặt riêng quyết định tổ chức sẽ có bao nhiêu tự do hành động sau năm năm nữa — và tự do hành động, như cuốn sách này lập luận xuyên suốt, là một tài sản kinh tế.

Các khái niệm cốt lõi

Kỹ thuật phần mềm là việc thiết kế, xây dựng và bảo trì phần mềm một cách có kỷ luật — và từ bảo trì mang phần lớn kinh tế học. Khác với một tòa nhà, phần mềm không bao giờ hoàn tất: yêu cầu dịch chuyển, quy định thay đổi, các phụ thuộc già đi, và các mối đe dọa an ninh tiến hóa. Bảo trì phần mềm — công việc khắc phục, thích ứng và phòng ngừa trên một hệ thống đang vận hành — thường hấp thụ phần lớn chi phí cả vòng đời của hệ thống. Đơn vị phân tích kinh tế vì thế không bao giờ là việc mua; đó là tổng chi phí sở hữu: mua sắm cộng tích hợp, di chuyển dữ liệu, đào tạo, lưu trữ, hỗ trợ, nâng cấp, bảo mật và ngừng sử dụng cuối cùng, trong vòng đời thực tế của hệ thống.

Khái niệm thứ hai là nợ kỹ thuật: chi phí tương lai ngụ ý của việc chọn một thiết kế tiện lợi bây giờ thay vì một thiết kế vững chắc. Phép ẩn dụ đủ chính xác để dùng trong một cuộc họp tài chính. Nợ không vốn xấu — một lối tắt có chủ ý đưa một năng lực cần thiết ra sớm hơn có thể là một khoản vay hợp lý — nhưng nó sinh lãi: mọi thay đổi tương lai đối với hệ thống tốn hơn vì nó, và nợ không được quản lý cộng dồn cho đến khi thay đổi trở nên đắt hoặc nguy hiểm đến mức cấm đoán. Một tổ chức y tế không thấy nợ kỹ thuật của mình đang gánh một khoản nợ phải trả chưa ghi sổ, đúng như thể nó có khoản vay không được ghi nhận.

Thứ ba, hệ thống kế thừa: phần mềm còn được dùng quá điểm mà nó có thể được bảo trì một cách kinh tế — thường vì nó vẫn chạy, mọi người phụ thuộc vào nó, và thay thế nó thật đáng sợ. Hệ thống kế thừa là nợ kỹ thuật ở quy mô tổ chức, và nó đặt ra một vấn đề thẩm định thực sự: chi phí giữ nó (bảo trì tăng, phơi bày an ninh, nhân viên không còn tuyển được, các cải tiến bị chặn ở nơi khác) khuếch tán và từ từ, trong khi chi phí thay thế thì tập trung, dễ thấy và rủi ro về chính trị. Các hệ thống y tế khắp thế giới chạy các dịch vụ trọng yếu trên phần mềm có tuổi hàng thập kỷ chính vì lý do này.

Thứ tư, sự phụ thuộc. Khóa chặt nhà cung cấp là tình trạng trong đó chuyển khỏi một nhà cung cấp tốn kém đến mức — về di chuyển dữ liệu, đào tạo lại, tích hợp lại và gián đoạn lâm sàng — người mua đã mất sức thương lượng hiệu quả. Trong y tế nó bị làm trầm trọng bởi dữ liệu: một thập kỷ hồ sơ bệnh nhân giữ ở định dạng độc quyền là một con tin. Khóa chặt không phải tai nạn; nó là một chiến lược định giá, và thời điểm định giá nó là trước khi ký, không phải lúc gia hạn. Các đối trọng mang tính hợp đồng (quyền xuất dữ liệu, ký quỹ mã nguồn, hỗ trợ thoát) và kiến trúc — trên hết là các chuẩn.

Thứ năm, khả năng tương tác: khả năng các hệ thống trao đổi thông tin và dùng điều được trao đổi. Kinh tế học của nó là kinh tế học của hiệu ứng mạng — mỗi hệ thống nói một chuẩn chung nâng giá trị của mọi hệ thống khác — đó là lý do khả năng tương tác bị thị trường cung ứng thiếu kinh niên: lợi ích tích tụ cho hệ thống như một tổng thể trong khi chi phí rơi lên từng nhà cung cấp và người mua, và một bên đương nhiệm có thể kiếm lời từ việc không tương tác. Các chuẩn như Fast Healthcare Interoperability Resources (FHIR), họ HL7 mà nó thuộc về, và openEHR tồn tại để giảm các chi phí trao đổi này, và các cơ quan quản lý — ví dụ Hoa Kỳ qua các quy tắc chống chặn thông tin của Đạo luật Chữa bệnh Thế kỷ 21, và Liên minh châu Âu qua Không gian Dữ liệu Y tế châu Âu — đã bắt đầu bắt buộc điều mà thị trường không cung cấp.

Thứ sáu, quang phổ tự xây–mua, gồm phần mềm nguồn mở — phần mềm có mã nguồn được tự do sử dụng và sửa đổi. Nguồn mở không miễn phí: chi phí giấy phép biến mất, nhưng triển khai, lưu trữ và quản lý vẫn còn, và ai đó phải bảo trì mã. Điểm khác biệt kinh tế của nó thuộc loại khác — nó loại bỏ phụ phí khóa chặt và biến phần mềm thành một của chung nhiều người mua có thể cùng tài trợ, đó là lý do các nền tảng như DHIS2 và OpenMRS gánh phần lớn tải thông tin y tế ở các nước thu nhập thấp và trung bình. Quyết định xây hay mua, tương tự, không phải sở thích công nghệ mà là câu hỏi danh mục: hãy xây nơi năng lực mang tính khác biệt và tổ chức có thể duy trì một đội kỹ thuật; hãy mua nơi nhu cầu là hàng hóa phổ thông; và đừng bao giờ xây thứ bạn không thể bảo trì.

Cuối cùng, độ tin cậy như một đại lượng kinh tế. Phần mềm lâm sàng chạy các dịch vụ mà thời gian ngừng hoạt động có chi phí sức khỏe, nên các kỷ luật kỹ thuật giữ hệ thống đáng tin cậy — gồm kỹ thuật độ tin cậy hệ thống, quản lý độ tin cậy theo các mục tiêu tường minh và lập ngân sách cho sự cố chấp nhận được — được hiểu tốt nhất như mua bảo hiểm với phí bảo hiểm là nỗ lực kỹ thuật. Độ tin cậy vượt mức cần của bối cảnh lâm sàng là lãng phí; dưới mức đó, phần thiếu hụt được trả bằng các sự cố. Bộ máy thẩm định cho tất cả điều này vẫn là Chủ đề 2.1 — Đánh giá kinh tế và kỷ luật khả năng chi trả của Chủ đề 2.5 — Tác động ngân sách và khả năng chi trả; chủ đề này cung cấp cấu trúc chi phí đặc thù phần mềm mà các phương pháp đó phải được nạp. Đánh giá một công cụ số như một can thiệp sức khỏe — ứng dụng hay dịch vụ y tế từ xa có cải thiện kết cục ở mức chi phí chấp nhận được không — thuộc Chủ đề 5.2 — Kinh tế sức khỏe số; kinh tế học của các mô hình AI nói riêng thuộc Chủ đề 5.3 — Kinh tế trí tuệ nhân tạo trong y tế.

Các thực hành tốt nhất

1. Thẩm định tổng chi phí sở hữu trong vòng đời thực tế của hệ thống, không bao giờ theo giá mua. Hãy đòi mọi luận chứng kinh doanh phần mềm tính chi phí mua sắm, tích hợp, di chuyển dữ liệu, đào tạo, lưu trữ, hỗ trợ, bảo mật, nâng cấp và ngừng sử dụng trong một chân trời đã nêu — thường là một thập kỷ hoặc hơn — và gọi tên ngân sách nào gánh từng dòng lặp lại. Một khoản phí giấy phép so với không gì cả không phải luận chứng kinh doanh; đó là chóp nhìn thấy của một cam kết.

2. Đưa nợ kỹ thuật vào sổ sách. Hãy để các lãnh đạo kỹ thuật duy trì một sổ đăng ký các lối tắt và thành phần cũ đáng kể trong hệ thống, với một ước lượng trung thực về lãi mà mỗi cái đang tính — thay đổi chậm hơn, rủi ro sự cố cao hơn, cải tiến bị chặn. Hãy xem xét nó với sự nghiêm túc như một khoản nợ tài chính, và lập ngân sách một phần năng lực kỹ thuật thường trực (thường từ một phần năm đến một phần ba) để trả nợ, vì trả nợ bị hoãn là nợ cộng dồn.

3. Tài trợ bảo trì như một chi phí vận hành từ ngày đầu. Phần mềm "đã hoàn tất" là phần mềm đang mục nát: các phụ thuộc già đi, mối đe dọa tiến hóa, quy định thay đổi. Hãy xây dòng bảo trì vào thẩm định ban đầu và ngân sách lặp lại, và coi một đề xuất không có dòng bảo trì là chưa đầy đủ — tiền sẽ được chi dù thế nào, và câu hỏi duy nhất là nó được lên kế hoạch hay bị một cuộc khủng hoảng rút ra.

4. Định giá sự khóa chặt trước khi ký, không phải lúc gia hạn. Với mọi vụ mua lớn, hãy tính chi phí lối thoát khi bạn còn các phương án: ai sở hữu dữ liệu, nó có thể xuất ở định dạng nào, nhà cung cấp phải hỗ trợ thoát gì, và một cuộc di chuyển có thể tốn bao nhiêu. Hãy thương lượng quyền xuất dữ liệu và giao diện mở vào hợp đồng, và coi sự kháng cự của nhà cung cấp là thông tin về cuộc thương lượng gia hạn sắp tới.

5. Mua khả năng tương tác một cách có chủ ý, vì thị trường cung ứng thiếu nó. Hãy đòi hỗ trợ các chuẩn mở — FHIR và các chuẩn cùng họ — làm điều kiện mua, xác minh sự tuân thủ tuyên bố dựa trên các luồng dữ liệu thực của bạn thay vì tờ rơi, và từ chối giao diện đặt riêng nơi có giao diện chuẩn. Mỗi giao diện độc quyền bạn chấp nhận là một chi phí chuyển đổi bạn đã tặng nhà cung cấp và một khoản thuế lên mọi tích hợp tương lai.

6. Quyết định xây hay mua như một danh mục, khớp với năng lực kỹ thuật của bạn. Chỉ xây nơi năng lực mang tính khác biệt cho dịch vụ của bạn và bạn có thể thực tế tuyển, giữ và tài trợ một đội để bảo trì thứ bạn xây — một hệ thống nội bộ không có đội thường trực là một hệ thống kế thừa với thêm vài bước. Hãy mua nhu cầu phổ thông; cân nhắc các nền tảng nguồn mở nơi một cộng đồng hay liên minh công duy trì chúng; và ghi kế hoạch duy trì vào quyết định, dù đi hướng nào.

7. Coi nguồn mở là một phương án mua sắm với cấu trúc chi phí riêng, không phải miễn phí. Hãy so sánh nó theo tổng chi phí sở hữu: không có phí giấy phép, nhưng có chi phí triển khai, lưu trữ, hỗ trợ và quản lý thực, dù gánh nội bộ hay qua một nhà cung cấp hỗ trợ. Hãy cân nhắc lợi ích đặc thù của nó — không có phụ phí khóa chặt, mã có thể kiểm tra, khả năng cùng tài trợ một của chung với các cơ quan y tế khác — và nghĩa vụ đặc thù của nó: nếu bạn phụ thuộc vào nó, hãy đóng góp để duy trì nó.

8. Đặt mục tiêu độ tin cậy từ hệ quả lâm sàng, và chi tiêu theo mục tiêu. Hãy quyết định, từng dịch vụ một, một giờ ngừng hoạt động thực sự tốn bao nhiêu — trong chăm sóc bị trì hoãn, cách làm tạm không an toàn và niềm tin bị mất — và đặt mục tiêu sẵn sàng và phục hồi cho phù hợp. Rồi giữ chi tiêu kỹ thuật theo mục tiêu từ cả hai phía: trả cho độ tin cậy ít hơn phòng khám cần là mua sự cố, và trả nhiều hơn mức cần là mua sự mạ vàng.

9. Lên kế hoạch thay thế hệ thống kế thừa trước khi nó bị ép buộc. Hãy xem xét tuổi và khả năng bảo trì của các hệ thống trọng yếu theo chu kỳ, và bắt đầu thay thế khi hệ thống đương nhiệm còn chạy — một cuộc di chuyển thực hiện lúc hỏng là loại đắt nhất. Hãy ưu tiên di chuyển tăng dần (bóp nghẹt hệ thống cũ từng giao diện một) hơn chuyển đổi đồng loạt, mà kiểu thất bại của nó trong y tế được đo bằng phòng khám bị hủy và hồ sơ bị mất.

10. Biến di chuyển dữ liệu thành một dòng hạng nhất trong mọi thẩm định. Dữ liệu bệnh nhân sống lâu hơn mọi hệ thống giữ nó, và di chuyển nó — sạch sẽ, đầy đủ, với an toàn lâm sàng được bảo đảm — thường nằm trong số các chi phí lớn nhất và bị đánh giá thấp nhất của mọi chuyển tiếp. Hãy tính chi phí tường minh, thử sớm với hồ sơ thật, và giữ quyền lưu giữ dữ liệu của bạn ở dạng xuất được trong suốt vòng đời của hệ thống để việc di chuyển không bao giờ bị nhà cung cấp rời đi làm con tin.

11. Giữ kỹ thuật an toàn lâm sàng bên trong kinh tế học. Phần mềm y tế là phần mềm liên quan đến an toàn: thay đổi cần kiểm thử, bản phát hành cần đường quay lui, sự cố cần điều tra, và các khu vực pháp lý ngày càng áp đặt chuẩn rủi ro lâm sàng chính thức lên CNTT y tế. Những kỷ luật này tốn thời gian kỹ thuật và thuộc về luận chứng kinh doanh — một việc giao "rẻ hơn" bỏ qua chúng là chuyển chi phí cho bệnh nhân dưới dạng rủi ro (chi phí của tác hại là Chủ đề 3.11 — Kinh tế chất lượng và an toàn).

12. Chuyển các quyết định phần mềm qua cùng sự soi xét giá trị như bất kỳ khoản đầu tư y tế nào khác. Một chương trình phần mềm cạnh tranh cùng ngân sách hạn chế với thuốc và nhân viên, nên nó nợ cùng kỷ luật: một lợi ích đã nêu, một đối chứng thực (gồm "cải thiện cái ta có"), một hồ sơ khả năng chi trả theo thời gian, và đánh giá sau triển khai đối chiếu với những lời hứa đã đưa ra (bộ máy là Chủ đề 2.1 — Đánh giá kinh tế và Chủ đề 2.5 — Tác động ngân sách và khả năng chi trả, và nghề mua sắm là Chủ đề 3.10 — Mua sắm chiến lược và đặt hàng dịch vụ).

Các câu hỏi để thảo luận với nhóm của bạn

1. Hệ thống phần mềm của chúng ta thực sự tốn bao nhiêu mỗi năm, và bao nhiêu trong đó chúng ta đã lên kế hoạch? Hầu hết tổ chức có thể nêu phí giấy phép nhưng không nêu chi phí tích hợp, bảo trì, bảo mật và làm tạm, vốn ẩn trong ngân sách vận hành và thời gian nhân viên khắp tổ chức. Hãy yêu cầu nhóm tập hợp con số thực hằng năm cho vài hệ thống hàng đầu và so với những gì luận chứng kinh doanh ban đầu đã hứa. Mâu thuẫn là các chi phí khuếch tán không có một chủ duy nhất, nên không ai chịu trách nhiệm về sự tăng của chúng, và những người phê duyệt vụ mua hiếm khi là những người trả tiền duy trì. Một câu trả lời trung thực đưa ra một con số trọn vòng đời, gọi tên ngân sách nào gánh nó, và thừa nhận nơi chi tiêu không được lên kế hoạch — vì một chi phí bạn phát hiện hằng năm sau khi đã xảy ra là chi phí bạn không thể quản lý.

2. Nợ kỹ thuật của chúng ta ở đâu, và chúng ta đang trả lãi bao nhiêu cho nó? Các đội kỹ thuật thường biết chính xác nợ ở đâu — mô-đun không ai dám đụng, giao diện được giữ bằng các bước thủ công, nền tảng chậm hai phiên bản so với hỗ trợ bảo mật — nhưng kiến thức hiếm khi đến hội đồng bằng ngôn ngữ kinh tế. Hãy yêu cầu sổ đăng ký: các khoản nợ đáng kể, mỗi khoản làm chậm hay gây nguy hiểm điều gì, và trả nó sẽ tốn bao nhiêu. Mâu thuẫn là việc trả nợ cạnh tranh với các tính năng mới dễ thấy và luôn thua về hình ảnh, chính là cách nợ cộng dồn. Một câu trả lời trung thực định lượng lãi (giao hàng chậm hơn, phơi bày sự cố, dự án bị chặn), cam kết một phần năng lực thường trực cho việc giảm nợ, và chấp nhận rằng gánh một số nợ là hợp lý — miễn là gánh có ý thức.

3. Nếu phải rời nhà cung cấp hệ thống chính của mình sau ba năm, chúng ta có làm được không — và nó sẽ tốn bao nhiêu? Câu hỏi này làm lộ sự khóa chặt khi còn thời gian để giảm nó. Hãy dò ai sở hữu dữ liệu và nó có thể rời đi ở định dạng nào, hợp đồng nói gì về hỗ trợ thoát, bao nhiêu giao diện đặt riêng sẽ cần xây lại, và việc đào tạo lại cùng gián đoạn lâm sàng nào một cuộc di chuyển sẽ áp đặt. Mâu thuẫn là ai cũng hy vọng không bao giờ phải dùng lối thoát, nên không ai muốn trả tiền để giữ nó mở — vậy mà một lối thoát bất khả là một cuộc thương lượng gia hạn đã thua. Một câu trả lời trung thực định giá lối thoát, xác định hai hay ba hành động sẽ làm nó rẻ hơn (quyền xuất dữ liệu, giao diện chuẩn, tài liệu), và coi mức giá đó như một vị thế thương lượng mà tổ chức chủ động duy trì.

4. Hệ thống nào chúng ta nên xây, hệ thống nào nên mua, và năng lực kỹ thuật của ta có khớp với câu trả lời đó không? Việc chia xây–mua là một quyết định danh mục mà nhiều tổ chức đưa ra bằng sự tích tụ thay vì lựa chọn, cuối cùng xây các hàng hóa phổ thông và mua cái làm nên sự khác biệt của mình. Hãy hỏi hệ thống nào của bạn thực sự thể hiện điều đặc thù về dịch vụ của bạn và hệ thống nào là nhu cầu phổ thông mà một thị trường hay cộng đồng nguồn mở đã phục vụ. Rồi thử tuyên bố về năng lực: với mọi thứ xây nội bộ, có một đội được tài trợ, tuyển được, cam kết bảo trì nó suốt vòng đời — không chỉ dự án đã tạo ra nó? Mâu thuẫn là xây tâng bốc tham vọng và mua tâng bốc sự thận trọng, và không bản năng nào là một phân tích. Một câu trả lời trung thực gọi tên các yếu tố khác biệt, thừa nhận nơi các bản xây trước nên nghỉ hưu hoặc được thay bằng sản phẩm chuẩn, và từ chối bắt đầu bất kỳ bản xây nào mà việc bảo trì không được tài trợ.

5. Một giờ ngừng hoạt động trong hệ thống trọng yếu nhất của chúng ta thực sự tốn bao nhiêu, và chi tiêu độ tin cậy của ta có khớp với nó không? Các quyết định độ tin cậy thường do kỹ sư đưa ra mà thiếu thông tin chi phí lâm sàng, hoặc do hội đồng đưa ra mà thiếu thông tin chi phí kỹ thuật, nên chi tiêu khớp với thói quen thay vì hệ quả. Hãy đi qua một kịch bản cụ thể: hồ sơ điện tử ngừng hoạt động suốt một ngày bận rộn — cái gì bị trì hoãn, cách làm tạm không an toàn nào xuất hiện, tác hại nào có thể xảy ra, phục hồi tốn bao nhiêu? Rồi so với những gì bạn chi cho khả năng chống chịu, sao lưu, chuyển đổi dự phòng và phản ứng sự cố. Mâu thuẫn chạy cả hai chiều: chi thiếu mua sự cố, nhưng mạ vàng một hệ thống rủi ro thấp lãng phí tiền mà dịch vụ khác cần. Một câu trả lời trung thực đặt một mục tiêu sẵn sàng và phục hồi tường minh cho mỗi dịch vụ trọng yếu, rút ra từ hệ quả lâm sàng, và có thể cho thấy chi tiêu kỹ thuật đáp ứng nó — không hơn, không kém.

6. Kế hoạch của chúng ta cho các hệ thống kế thừa mà ai cũng sợ đụng vào là gì? Mọi tổ chức y tế trưởng thành đều có chúng: các hệ thống quá khả năng bảo trì kinh tế, được giữ sống vì chúng chạy và thay thế thì đáng sợ. Hãy gọi tên của bạn. Hãy hỏi mỗi cái đang chặn điều gì — các tích hợp chưa xây, các cải tiến chưa làm, phơi bày an ninh đang gánh — và con đường thay thế là gì: di chuyển tăng dần, thay thế toàn bộ, hay giữ lại có chủ ý, có kế hoạch với rủi ro được kiềm chế. Mâu thuẫn mang tính thời gian: chi phí giữ hệ thống kế thừa khuếch tán và hằng năm trong khi chi phí thay thế tập trung và hiện rõ trên sự nghiệp, nên việc trì hoãn trông hợp lý là mặc định cho đến khi thất bại buộc vấn đề ở mức giá tồi tệ nhất có thể. Một câu trả lời trung thực lên lịch thay thế khi hệ thống đương nhiệm còn chạy, ưu tiên di chuyển tăng dần kiểu bóp nghẹt hơn chuyển đổi đồng loạt, và coi "năm sau chúng ta sẽ quyết định" là quyết định mà nó thực sự là.

Trong thực tế: một ví dụ về kinh tế học sức khỏe

Bộ Y tế của một nước Đông Phi hư cấu đối mặt một quyết định gia hạn. Chín năm nay các bệnh viện khu vực của nước này chạy một hệ thống thông tin bệnh viện độc quyền do một nhà cung cấp nước ngoài cung cấp. Hệ thống chạy được, nhưng báo giá gia hạn đã tăng mạnh, mọi giao diện mới — tới chương trình bảo hiểm quốc gia, tới mạng lưới xét nghiệm — là một dự án đặt riêng, tính giá theo nhà cung cấp, và hợp đồng im lặng về xuất dữ liệu. Trong khi đó các văn phòng y tế quận của bộ đã chạy DHIS2, nền tảng nguồn mở dùng cho thống kê y tế quốc gia, và một nước láng giềng đã triển khai một nền tảng hồ sơ y tế nguồn mở với một liên minh hỗ trợ khu vực.

Đơn vị kinh tế y tế của bộ đặt lại khung quyết định từ "gia hạn hay không" thành một so sánh trọn vòng đời giữa ba phương án trong mười năm: gia hạn hệ thống đương nhiệm, gia hạn ngắn hạn trong khi xây quyền thoát, hoặc di chuyển tăng dần sang nền tảng nguồn mở. Tính chi phí các phương án phơi bày kinh tế học thực. Giấy phép của hệ thống đương nhiệm chỉ là một phần ba chi phí hằng năm thực của nó khi tính các giao diện đặt riêng, các dự án nâng cấp bắt buộc và chi phí đi lại hỗ trợ ở nước ngoài. Phương án nguồn mở không có giấy phép nhưng đòi bộ tài trợ một đội hỗ trợ quốc gia, lưu trữ khu vực và một khoản đóng góp cho cộng đồng nền tảng — tiền thực, lặp lại mà luận điệu "phần mềm miễn phí" đã che giấu. Tuy nhiên dòng quyết định không phải hai cái này: đó là di chuyển dữ liệu. Chín năm hồ sơ bệnh nhân nằm trong một lược đồ độc quyền, và giá của nhà cung cấp cho hỗ trợ trích xuất, thực chất, là giá của việc rời đi.

Đơn vị dù sao cũng định giá lối thoát, và con số thay đổi cuộc thương lượng. Có trong tay một phương án đã tính chi phí, bộ thương lượng một lần gia hạn hai năm ở giá thấp hơn, gồm việc xuất dữ liệu theo hợp đồng ở một định dạng có tài liệu và các giao diện FHIR chuẩn tới chương trình bảo hiểm và mạng lưới xét nghiệm — được mua, về kinh tế, như một quyền chọn đối với một lối thoát rẻ hơn trong tương lai, được định giá theo cách Chủ đề 3.12 — Kinh tế ứng phó đại dịch và tình huống khẩn cấp định giá mọi quyền chọn về tự do hành động trong tương lai. Trong hai năm đó, một thí điểm di chuyển ba bệnh viện quận sang nền tảng nguồn mở, thử liên minh hỗ trợ, công cụ di chuyển dữ liệu và — then chốt — liệu bộ có thể tuyển và giữ các kỹ sư mà nền tảng cần, dựa vào kinh tế học lực lượng lao động của Chủ đề 3.6 — Lực lượng lao động y tế và thị trường lao động.

Thí điểm thành công ở hai bệnh viện và chật vật ở bệnh viện thứ ba, nơi những khoảng trống nhân sự biến mọi sự cố thành khủng hoảng — một cảnh báo về năng lực, không phải phần mềm. Bộ tiến hành một cuộc di chuyển quốc gia theo giai đoạn trong năm năm, từng bệnh viện một, giữ hệ thống đương nhiệm chạy song song cho đến khi dữ liệu của mỗi địa điểm được xác minh. Đánh giá cuối cùng làm bài học tường minh: nước đi thắng không phải chọn nguồn mở hơn độc quyền, mà là định giá trọn vòng đời của mỗi phương án, mua quyền thoát trước khi sự phụ thuộc cứng thêm, và khớp cam kết kỹ thuật với điều bộ có thể thực sự duy trì.

Bốn góc nhìn theo khu vực

Công ty khởi nghiệp

Một công ty khởi nghiệp phần mềm y tế sống với kinh tế học của chủ đề này từ phía bán: định giá của nó thưởng cho tốc độ giao hàng, chính là cách nợ kỹ thuật tích tụ, và mô hình doanh thu của nó có thể lặng lẽ phụ thuộc vào sự khóa chặt mà khách hàng của nó nên chống lại. Kỷ luật là vay nợ có chủ ý — một lối tắt giành được một khách hàng then chốt có thể hợp lý — trong khi giữ một sổ đăng ký và một kế hoạch trả nợ, vì một cơ sở mã không thể thay đổi là một công ty không thể xoay chuyển. Khả năng tương tác là chiến lược, không phải tuân thủ: giao diện chuẩn (trên hết là FHIR) là cách một sản phẩm nhỏ giành chỗ trong các hệ thống do bên đương nhiệm thống trị. Và kỹ thuật an toàn lâm sàng không phải thủ tục để hoãn đến khi có quy mô; một sự cố toàn vẹn dữ liệu trong bối cảnh lâm sàng có thể chấm dứt một công ty non trẻ.

Doanh nghiệp nhỏ

Một nhà cung cấp nhỏ nhưng đã thành lập — một nhóm phòng khám, một chuỗi hiệu thuốc, một phòng xét nghiệm chẩn đoán — mua gần như toàn bộ phần mềm của mình và không có nhân viên kỹ thuật để bù đắp cho một vụ mua tồi, nên kinh tế học của nó là kinh tế học của sự phụ thuộc. Tổng chi phí sở hữu và quyền thoát quan trọng ở đây hơn bất kỳ nơi nào, vì một hệ thống bị định giá sai chiếm tỷ lệ lớn hơn của ngân sách và một cuộc di chuyển thất bại có thể làm ngưng doanh nghiệp. Tư thế hợp lý là chuẩn hóa: sản phẩm phổ biến, giao diện chuẩn mở, dịch vụ được lưu trữ thay vì máy chủ tự vận hành, và hợp đồng được đọc để tìm điều khoản xuất dữ liệu trước giá. Rủi ro đặc thù của nó là hệ thống kế thừa thầm lặng — hệ thống quản lý phòng khám già đi tại chỗ cho đến khi nhà cung cấp của nó sụp đổ — nên ngay cả một người mua nhỏ cũng nên biết, mỗi năm, rời mỗi hệ thống mà nó phụ thuộc sẽ tốn bao nhiêu.

Doanh nghiệp lớn

Một nhóm bệnh viện hay công ty bảo hiểm lớn chạy hàng trăm hệ thống, nên vấn đề của nó là danh mục: các sản phẩm chồng chéo do các khoa khác nhau mua, một mạng tích hợp không ai lập bản đồ đầy đủ, và nợ kỹ thuật phân bố trên một hệ thống quá lớn để bất kỳ đội nào thấy được. Doanh nghiệp lớn trưởng thành quản lý hệ thống như cách nó quản lý một danh mục đầu tư — một kiểm kê các hệ thống với người chủ, chi phí trọn vòng đời, xếp hạng nợ và rủi ro, và chân trời thay thế đã lên kế hoạch — và tài trợ một năng lực kỹ thuật thường trực cho tích hợp, độ tin cậy và trả nợ thay vì coi mọi cải tiến là một dự án phải đấu thầu. Quy mô cũng cho nó sức mua mà người mua nhỏ hơn không có: nó có thể đòi giao diện chuẩn, quyền xuất dữ liệu và ký quỹ mã nguồn làm điều kiện vào, và các lựa chọn kiến trúc của nó kỷ luật nhà cung cấp chứ không phải ngược lại.

Chính phủ

Một bộ hay bên chi trả quốc gia định hình kinh tế học này cho mọi người khác. Nó đặt các quy tắc tương tác quyết định thị trường thưởng hay phạt sự cởi mở — như Hoa Kỳ đã làm với các điều khoản chống chặn thông tin của Đạo luật Chữa bệnh Thế kỷ 21 và Liên minh châu Âu với Không gian Dữ liệu Y tế châu Âu — và mua sắm của chính nó dạy nhà cung cấp điều người mua sẽ chịu đựng. Kiểu thất bại đặc thù của nó là chương trình khổng lồ quốc gia: việc giao phần mềm tập trung, đồng loạt, theo lịch trình chính trị mà sự sụp đổ được đo bằng hàng tỷ, như Chương trình Quốc gia về CNTT của Anh đã chứng minh. Kỷ luật là tư thế ngược lại — chuẩn và nền tảng ở trung ương, giao hàng tăng dần, với các phương án nguồn mở và bảo trì được tại địa phương được cân nhắc nghiêm túc nơi thị trường thương mại mỏng (bộ máy chính sách là Chủ đề 3.2 — Chính sách y tế, và nghề mua sắm là Chủ đề 3.10 — Mua sắm chiến lược và đặt hàng dịch vụ).

Các kiểu thất bại thường gặp

• Mua giấy phép, không mua vòng đời. Phê duyệt phần mềm theo giá mua trong khi tích hợp, di chuyển, bảo trì và lối thoát không được tính chi phí. Cách khắc phục: đòi tổng chi phí sở hữu trọn vòng đời, với ngân sách có tên cho mọi dòng lặp lại, trong mọi luận chứng kinh doanh.

• Nợ vô hình cho đến khi cộng dồn. Để nợ kỹ thuật tích tụ không ghi chép cho đến khi hệ thống không thể thay đổi một cách an toàn. Cách khắc phục: giữ sổ đăng ký nợ, báo cáo nó bằng ngôn ngữ kinh tế, và cam kết năng lực thường trực cho việc trả nợ.

• Mộng du vào sự khóa chặt. Chấp nhận định dạng độc quyền và giao diện đặt riêng cho đến khi lối thoát không đủ khả năng chi trả và các lần gia hạn bị áp đặt. Cách khắc phục: thương lượng quyền xuất dữ liệu và giao diện chuẩn khi mua, và định giá lối thoát hằng năm.

• Xây thứ bạn không thể bảo trì. Đặt hàng hệ thống nội bộ mà không có đội được tài trợ trong toàn bộ vòng đời. Cách khắc phục: không xây nếu không có kế hoạch duy trì; mua hoặc áp dụng nền tảng nguồn mở nơi năng lực mỏng.

• Coi nguồn mở là miễn phí. Áp dụng nền tảng cộng đồng mà không tài trợ lưu trữ, hỗ trợ và quản lý. Cách khắc phục: thẩm định nguồn mở theo tổng chi phí sở hữu và lập ngân sách cho sự duy trì nó cần.

• Độ tin cậy bằng hy vọng. Để mục tiêu sẵn sàng không được đặt cho đến khi một sự cố ngừng hoạt động lộ ra chi phí lâm sàng của thời gian ngừng. Cách khắc phục: đặt mục tiêu sẵn sàng và phục hồi cho mỗi dịch vụ trọng yếu từ hệ quả lâm sàng, và chi tiêu theo mục tiêu.

• Thay thế hệ thống kế thừa đồng loạt dưới sức ép. Hoãn hiện đại hóa cho đến khi thất bại buộc một cuộc chuyển đổi vội vàng, toàn diện. Cách khắc phục: lên kế hoạch thay thế khi hệ thống đương nhiệm còn chạy, và di chuyển tăng dần với vận hành song song và dữ liệu được xác minh.

• Phần mềm ngoài kỷ luật giá trị. Để các chương trình CNTT bỏ qua sự soi xét áp dụng cho thuốc và dịch vụ. Cách khắc phục: cùng quy tắc — lợi ích đã nêu, đối chứng thực, hồ sơ khả năng chi trả, đánh giá sau triển khai.

Mô hình trưởng thành

Danh mục kiểm tra

• Thẩm định mọi quyết định phần mềm theo tổng chi phí sở hữu trong vòng đời thực tế của nó, với ngân sách có tên cho mỗi dòng lặp lại.
• Duy trì một sổ đăng ký nợ kỹ thuật, báo cáo nó bằng ngôn ngữ kinh tế, và cam kết năng lực kỹ thuật thường trực cho việc trả nợ.
• Tài trợ bảo trì như một chi phí vận hành đã lên kế hoạch từ luận chứng kinh doanh ban đầu trở đi.
• Thương lượng quyền xuất dữ liệu, giao diện chuẩn và hỗ trợ thoát vào hợp đồng khi mua.
• Định giá lối thoát khỏi mỗi hệ thống lớn hằng năm, và giữ một phương án đã tính chi phí còn sống trước các lần gia hạn.
• Đòi sự tuân thủ chuẩn mở đã xác minh (ví dụ FHIR) làm điều kiện mua.
• Quyết định xây hay mua như một danh mục, và không bắt đầu bản xây nào nếu không có kế hoạch duy trì trọn vòng đời được tài trợ.
• Thẩm định các phương án nguồn mở theo tổng chi phí sở hữu, lập ngân sách cho lưu trữ, hỗ trợ và quản lý.
• Đặt mục tiêu sẵn sàng và phục hồi cho mỗi dịch vụ trọng yếu từ hệ quả lâm sàng, và khớp chi tiêu với chúng.
• Lên lịch thay thế hệ thống kế thừa khi hệ thống đương nhiệm còn chạy, ưu tiên di chuyển tăng dần hơn chuyển đổi đồng loạt.
• Tính chi phí và thử di chuyển dữ liệu sớm, và giữ dữ liệu bệnh nhân xuất được trong suốt vòng đời mỗi hệ thống.
• Chuyển các chương trình phần mềm qua cùng sự soi xét giá trị như bất kỳ khoản đầu tư y tế nào khác, với đánh giá sau triển khai.

Nguồn chính

• WHO, Global Strategy on Digital Health 2020–2025 — khung của Tổ chức Y tế Thế giới cho đầu tư sức khỏe số, gồm các nguyên tắc bền vững và khả năng tương tác.
• HL7 International — chuẩn FHIR (Fast Healthcare Interoperability Resources), chuẩn mở chủ đạo cho trao đổi dữ liệu y tế.
• openEHR, DHIS2 và OpenMRS — các nền tảng và đặc tả thông tin y tế nguồn mở được triển khai rộng rãi trên thế giới, những ví dụ điển hình về phần mềm y tế do cộng đồng duy trì.
• Văn phòng Điều phối Quốc gia về CNTT Y tế Hoa Kỳ (nay là ASTP) — các quy tắc chống chặn thông tin và khả năng tương tác của Đạo luật Chữa bệnh Thế kỷ 21, một phản ứng quản lý với khả năng tương tác bị cung ứng thiếu.
• DORA, các báo cáo Accelerate State of DevOps — nghiên cứu lâu năm liên kết thực hành giao phần mềm và độ tin cậy với hiệu suất tổ chức.
• Văn phòng Kiểm toán Quốc gia Anh — các báo cáo về Chương trình Quốc gia về CNTT trong NHS, nghiên cứu điển hình kinh điển về thất bại của một chương trình CNTT y tế quy mô lớn.

Tài liệu tham khảo

1. Software engineering — Wikipedia — https://en.wikipedia.org/wiki/Software_engineering
2. Software maintenance — Wikipedia — https://en.wikipedia.org/wiki/Software_maintenance
3. Total cost of ownership — Wikipedia — https://en.wikipedia.org/wiki/Total_cost_of_ownership
4. Technical debt — Wikipedia — https://en.wikipedia.org/wiki/Technical_debt
5. Legacy system — Wikipedia — https://en.wikipedia.org/wiki/Legacy_system
6. Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
7. Interoperability — Wikipedia — https://en.wikipedia.org/wiki/Interoperability
8. Network effect — Wikipedia — https://en.wikipedia.org/wiki/Network_effect
9. Fast Healthcare Interoperability Resources — Wikipedia — https://en.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources
10. Health Level 7 — Wikipedia — https://en.wikipedia.org/wiki/Health_Level_7
11. Open-source software — Wikipedia — https://en.wikipedia.org/wiki/Open-source_software
12. Site reliability engineering — Wikipedia — https://en.wikipedia.org/wiki/Site_reliability_engineering
13. World Health Organization — Global Strategy on Digital Health 2020–2025 — https://www.who.int/publications/i/item/9789240020924
14. HL7 International — FHIR specification — https://hl7.org/fhir/
15. National Audit Office — The National Programme for IT in the NHS: an update on the delivery of detailed care records systems — https://www.nao.org.uk/reports/the-national-programme-for-it-in-the-nhs-an-update-on-the-delivery-of-detailed-care-records-systems/
16. National Programme for IT — Wikipedia — https://en.wikipedia.org/wiki/National_Programme_for_IT