Chủ đề 1.1 — Mô hình vận hành

Tóm lại trong một câu: Mô hình vận hành mục tiêu (TOM) là việc thiết kế có chủ đích cách chiến lược của tổ chức bạn chảy qua các dòng giá trị, năng lực, nhóm, quản trị, công nghệ, dữ liệu và nhà cung cấp để mang lại các kết quả y tế và chăm sóc số — và việc định hình đúng nó quyết định liệu mọi thứ phía sau sẽ nhanh và an toàn hay chậm và dễ vỡ.

Vì sao điều này quan trọng trong y tế và chăm sóc#

Hầu hết các tổ chức y tế số không thất bại vì thiếu nhân tài hay công nghệ; họ thất bại vì mô hình vận hành của họ chống lại chính họ. Nguồn tài trợ gắn với các dự án có thời hạn, quyền ra quyết định mơ hồ, và mỗi nhóm lại xây lại cùng một hạ tầng đăng nhập, tích hợp và kiểm toán. Kết quả là chi phí trùng lặp trên tiền công, an toàn lâm sàng thiếu nhất quán, và các dịch vụ không thể chia sẻ dữ liệu trong một hệ thống chăm sóc tích hợp (ICS).

Mô hình vận hành mang nét đặc thù trong lĩnh vực này vì nó phải dung hòa những điều tốt đẹp cạnh tranh nhau. Nó phải đủ liên bang để tôn trọng quyền tự chủ của các tổ chức có chủ quyền — các bệnh viện, chính quyền địa phương, phòng khám bác sĩ gia đình — nhưng cũng đủ mạch lạc để mang lại cho bệnh nhân một trải nghiệm an toàn xuyên suốt chúng. Nó phải cân bằng giữa vận hành (giữ cho các hệ thống lâm sàng sẵn sàng một cách an toàn) và thay đổi (cải thiện chúng), khi thời gian ngừng hoạt động có thể ảnh hưởng đến việc chăm sóc. Và nó phải chi tiêu tương xứng: đảm bảo đủ nặng cho trách nhiệm giải trình công và an toàn lâm sàng, đủ nhẹ để không bóp nghẹt việc lặp lại. TOM là nơi những đánh đổi đó được làm rõ thay vì để mặc cho ngẫu nhiên.

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

Các tầng của một mô hình vận hành. Một TOM hữu ích là một chồng các tầng, mỗi tầng phục vụ tầng phía trên:

• Chiến lược và kết quả — các kết quả đo lường được về dân số và dịch vụ mà bạn tồn tại để cải thiện (thường được diễn đạt dưới dạng OKR; xem Chủ đề 1.3 — Quyết định dựa trên bằng chứng).
• Dòng giá trị — các luồng đầu cuối mang lại giá trị cho người dùng, ví dụ "chuyển tuyến, phân loại và điều trị một bệnh nhân" — được tổ chức quanh hành trình của người dân, không phải sơ đồ tổ chức.
• Năng lực — những điều bạn phải có khả năng làm (danh tính, đặt lịch hẹn, ghi chép lâm sàng, phân tích). Năng lực ổn định ngay cả khi các giải pháp thay đổi.
• Nhóm — những con người được tổ chức để cung cấp các năng lực và dòng giá trị (xem Team Topologies bên dưới).
• Quản trị và quyền ra quyết định — ai quyết định điều gì, và đảm bảo được áp dụng ra sao.
• Công nghệ và dữ liệu — các nền tảng, chuẩn và kiến trúc dữ liệu mà các nhóm xây dựng trên đó.
• Nhà cung cấp — thị trường bạn mua hàng và cách bạn quản lý nó.

Thiết kế từ trên xuống (chiến lược → dòng giá trị → năng lực) giữ cho các nhóm và công nghệ bám theo kết quả thay vì bám theo các cấu trúc cũ.

Mô hình tập trung, liên bang và nền tảng. Mô hình tập trung dồn việc triển khai vào một nhóm hoặc cơ quan độc lập: nhất quán và rẻ để chuẩn hóa, nhưng là điểm nghẽn và thường xa rời nhu cầu địa phương. Mô hình liên bang phân quyền triển khai cho các bệnh viện và địa phương: đáp ứng nhanh và do địa phương làm chủ, nhưng dễ trùng lặp và phân kỳ. Mô hình nền tảng là mẫu hình dung hòa: một nhóm trung tâm cung cấp các năng lực dùng chung, tái sử dụng được (danh tính, khả năng tương tác, lưu trữ, hệ thống thiết kế) dưới dạng một nền tảng, còn các nhóm liên bang xây dựng trên đó với tốc độ cao. Hầu hết các hệ thống y tế trưởng thành đều hội tụ về "nền tảng cộng liên bang".

Team Topologies. Khung này gọi tên bốn loại nhóm — nhóm bám dòng giá trị (sở hữu một dòng giá trị), nhóm nền tảng (cung cấp các năng lực tự phục vụ), nhóm hỗ trợ (huấn luyện người khác nâng một năng lực) và nhóm hệ thống con phức tạp (công việc chuyên sâu như một thuật toán) — và nhấn mạnh sự tương tác ít ma sát giữa chúng. Nó ánh xạ gọn gàng vào mô hình nền tảng: các nhóm nền tảng làm giảm gánh nặng nhận thức của các nhóm bám dòng giá trị để họ tập trung vào giá trị cho người dùng và lâm sàng.

Vận hành so với thay đổi. Vận hành là giữ cho các dịch vụ đang chạy an toàn và sẵn sàng; thay đổi là cải thiện hoặc xây dựng chúng. Các nhóm sản phẩm vừa xây vừa vận hành một dịch vụ ("bạn xây, bạn vận hành") khép kín vòng phản hồi và cải thiện an toàn, nhưng sự cân bằng phải được tài trợ một cách trung thực — bóp nghẹt vận hành để tài trợ thay đổi là cách các hệ thống lâm sàng xuống cấp.

Nền tảng khả thi mỏng nhất (TVP). Từ Team Topologies: một nền tảng nên là tập hợp nhỏ nhất các dịch vụ dùng chung thực sự giảm ma sát cho các nhóm dòng giá trị — không hơn. Một nền tảng xây quá mức sẽ trở thành điểm nghẽn và hệ thống cũ của chính nó. Hãy bắt đầu với vài năng lực mà mọi nhóm thực sự cần (xác thực, lớp tương tác, lưu trữ, hệ thống thiết kế) và chỉ mở rộng khi có nhu cầu được chứng minh.

Thực hành tốt nhất#

1. Thiết kế mô hình từ kết quả đi xuống, chứ không phải từ sơ đồ tổ chức đi lên. Bắt đầu với các kết quả về dân số và dịch vụ mà bạn phải thúc đẩy, suy ra các dòng giá trị mang lại chúng, và chỉ sau đó mới thiết kế nhóm và công nghệ. Một TOM neo vào hệ thống thứ bậc hiện có chỉ tự động hóa các ốc đảo hiện tại.

2. Áp dụng hình thái nền tảng cộng liên bang. Cung cấp các năng lực dùng chung tại trung tâm như một nền tảng tự phục vụ, và để các nhóm bám dòng giá trị ở các bệnh viện và địa phương xây dựng trên đó. Điều này mang lại cho bạn sự nhất quán toàn quốc về an toàn và khả năng tương tác cùng với tốc độ và quyền sở hữu địa phương — sự dung hòa mà lĩnh vực này đòi hỏi.

3. Tài trợ sản phẩm, không phải dự án. Chuyển tiền từ các dự án có giới hạn thời gian sang các nhóm sản phẩm được tài trợ bền vững gắn với các dòng giá trị. Tài trợ dự án buộc các nhóm giải tán đúng vào lúc họ đã học được lĩnh vực; tài trợ sản phẩm duy trì kiến thức an toàn và sự lặp lại mà các dịch vụ y tế cần (xem Chủ đề 5.0 — Công việc dẫn dắt bởi sản phẩm).

4. Làm cho kiểm soát chi tiêu tương xứng và theo giai đoạn. Dùng tài trợ theo giai đoạn gắn với bằng chứng — giải ngân ở các cổng khám phá, alpha, beta và vận hành thay vì phê duyệt cả chương trình ngay từ đầu. Các kiểm soát chi tiêu kiểu GDS và lộ trình đảm bảo của NHS tồn tại để ngăn các chi phí chìm lớn cho những ý tưởng chưa được kiểm chứng; hãy áp dụng chúng như các ngưỡng theo tỷ lệ rủi ro và giá trị, không phải quan liêu đại trà.

5. Làm rõ quyền ra quyết định bằng bản đồ RACI hoặc RAPID. Thẩm quyền mơ hồ là nguyên nhân phổ biến nhất khiến việc triển khai đình trệ. Với mỗi loại quyết định quan trọng, hãy nêu rõ ai Chịu trách nhiệm/Giải trình/Được tham vấn/Được thông báo (RACI) hoặc ai Đề xuất, Đồng ý, Thực hiện, có Ý kiến và Quyết định (RAPID). Hãy công bố nó để các nhóm ngừng đẩy lên cấp trên những quyết định mà họ được trao quyền tự đưa ra.

6. Giữ nền tảng mỏng và dẫn dắt bởi nhu cầu. Chỉ xây các năng lực dùng chung khi hai nhóm trở lên rõ ràng cần cùng một thứ, và xem nền tảng như một sản phẩm có người dùng riêng (các nhóm nội bộ). Hãy cưỡng lại sự thôi thúc xây trước một nền tảng vĩ đại; nền tảng khả thi mỏng nhất giành được phạm vi của mình nhờ sự chấp nhận.

7. Quản lý nhà cung cấp như một phần của mô hình, không phải bên ngoài nó. Quyết định có chủ đích năng lực nào mang tính chiến lược (tự xây/sở hữu) và năng lực nào là hàng hóa thông dụng (mua), tránh bị khóa chặt vào một nhà cung cấp duy nhất đối với dữ liệu lâm sàng cốt lõi, và yêu cầu chuẩn mở cùng quyền rút lui trong hợp đồng. Các nhà cung cấp của bạn là một tầng của mô hình vận hành, và phương thức làm việc của họ phải tương thích với của bạn.

8. Làm rõ quyền ra quyết định. Một mô hình vận hành chỉ hoạt động nếu mọi người biết ai quyết định điều gì — lựa chọn nào thuộc về một nhóm sản phẩm, lựa chọn nào thuộc về cơ quan an toàn lâm sàng, và lựa chọn nào phải lên đến hội đồng quản trị. Hãy lập bản đồ quyền ra quyết định và đẩy mỗi quyết định xuống cấp thấp nhất có thể gánh vác nó một cách an toàn, để việc triển khai không bị bóp nghẹt bởi leo thang không cần thiết. Thẩm quyền mơ hồ là một trong những nguyên nhân phổ biến nhất của triển khai chậm chạp, phòng thủ.

9. Xem mô hình vận hành như một sản phẩm bạn tiến hóa. Một mô hình vận hành mục tiêu không phải được đặt một lần rồi đóng khung treo tường; hãy kiểm tra nó khi nhu cầu, công nghệ và quan hệ đối tác thay đổi, và điều chỉnh theo bằng chứng. Theo dõi một vài tín hiệu — dòng chảy công việc, thời gian ra quyết định, việc làm lại và sức khỏe nhóm — và thay đổi cấu trúc khi chúng rõ ràng đang cản trở, chứ không phải để chạy theo mốt tái cơ cấu.

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

1. Mô hình vận hành của chúng ta được thiết kế từ kết quả và dòng giá trị đi xuống, hay nó chỉ đơn giản tự động hóa sơ đồ tổ chức hiện có cùng các ốc đảo của nó? Câu hỏi này đi thẳng vào cảnh báo trung tâm của chủ đề rằng một TOM neo vào hệ thống thứ bậc hiện tại chỉ củng cố các ốc đảo bạn đã có, nên đáng được đặt lên bàn trước mọi cuộc tái cơ cấu. Nó quan trọng trong bối cảnh y tế và chăm sóc vì các dòng giá trị đi theo hành trình của người dân — chuyển tuyến, phân loại, điều trị — xuyên qua các tổ chức có chủ quyền, trong khi sơ đồ tổ chức đi theo ranh giới thể chế, và một mô hình xây trên cái sau sẽ tiếp tục tạo ra các dịch vụ phân mảnh, không tương tác được bằng tiền công. Căng thẳng cần tranh luận một cách trung thực là thiết kế từ kết quả đi xuống thực sự gây xáo trộn: nó cắt ngang quyền sở hữu của các phòng ban, ngân sách và tuyến báo cáo mà những người cấp cao đã xây dựng sự nghiệp quanh đó, nên có một cái giá chính trị thực sự khi làm đúng cách. Hãy tự kiểm tra cụ thể bằng cách nêu tên ba kết quả hàng đầu và lần theo xem ranh giới nhóm và các dòng tài trợ thực tế của bạn đi theo các dòng giá trị đó hay theo các phòng ban; nếu các nhóm ánh xạ gọn vào các phòng ban thì đó là câu trả lời của bạn. Một phản hồi tốt, trung thực thừa nhận chỗ mô hình mang hình dạng sơ đồ tổ chức, xác định ít nhất một dòng giá trị hiện đang bị chia cắt qua các ốc đảo gây bất lợi, và thực tế về những ranh giới cấu trúc nào tổ chức sẵn lòng vẽ lại.

2. Điều gì thuộc về nền tảng khả thi mỏng nhất của chúng ta, và làm sao ngăn nó vừa bị xây quá mức thành điểm nghẽn, vừa bị xây thiếu khiến mọi nhóm lại xây cùng một hạ tầng? Hình thái nền tảng cộng liên bang chỉ hoạt động nếu nền tảng giữ được sự mỏng và dẫn dắt bởi nhu cầu, và câu hỏi này khiến nhóm đối diện với cả hai kiểu thất bại mà chủ đề nêu tên — nền tảng vĩ đại trở thành điểm nghẽn hệ thống cũ của chính nó, và sự vắng mặt buộc mọi nhóm xây lại đăng nhập, tích hợp và kiểm toán. Nó quan trọng vì trong một ICS nền tảng thực chất là hạ tầng dùng chung (danh tính, lớp tương tác FHIR, lưu trữ với các mức an toàn cơ sở, hệ thống thiết kế) và xác định sai phạm vi sẽ nhân chi phí hoặc ma sát lên trên mọi nhóm dòng giá trị. Sự đánh đổi cần tranh luận là về thời điểm và bằng chứng: xây quá sớm thì bạn đoán sai và tạo ra điểm nghẽn; xây quá muộn thì sự trùng lặp đã đông cứng — nên phép thử "hai nhóm trở lên rõ ràng cần cùng một thứ" là mấu chốt, và nhóm nên kiểm tra xem họ có thực sự áp dụng nó hay chỉ xây những gì có vẻ hiển nhiên là trung tâm. Hãy xem điều gì hiện được coi là nền tảng so với điều các nhóm xây lại, và hỏi nền tảng có được vận hành như một sản phẩm với người dùng nội bộ và SLA riêng hay như một hàng đợi mà mọi người chờ phía sau. Một câu trả lời trung thực nêu các năng lực cụ thể hiện vượt qua phép thử hai nhóm, cưỡng lại cám dỗ xây trước phần còn lại, và cam kết đối xử với người dùng nội bộ của nhóm nền tảng như khách hàng thực với mức dịch vụ thực.

3. Quyền ra quyết định của chúng ta thực sự mơ hồ ở đâu, và các nhóm hôm nay đang đẩy lên cấp trên những gì mà lẽ ra họ được trao quyền tự quyết? Thẩm quyền mơ hồ được nêu là nguyên nhân phổ biến nhất khiến triển khai đình trệ, nên câu hỏi này làm lộ ra ma sát hằng ngày mà bản đồ RACI hoặc RAPID được công bố nhằm loại bỏ. Nó đặc biệt quan trọng trong một hệ thống y tế liên bang nơi các nhóm địa phương, hội đồng số của ICS, an toàn lâm sàng và quản trị thông tin đều có yêu sách chính đáng đối với một quyết định, và ranh giới không rõ nghĩa là hoặc mọi thứ bị đẩy lên, hoặc tệ hơn, không ai sở hữu một quyết định cho đến khi nó hỏng. Căng thẳng đáng khám phá là việc phân quyền quyết định đòi hỏi tin tưởng các nhóm trong các giới hạn, điều mà lãnh đạo cấp cao và hội đồng thường chống lại đúng ở nơi liên quan đến an toàn lâm sàng hoặc tiền công — nhưng việc giữ lại sự tin tưởng đó chính là điều tạo ra tắc nghẽn leo thang ngay từ đầu. Hãy làm cho nó cụ thể bằng cách liệt kê năm quyết định gần nhất bị đẩy lên và hỏi, với mỗi quyết định, ai lẽ ra phải quyết định và giới hạn nào sẽ cho phép họ làm vậy; mô thức thường phơi bày một số ít loại quyết định mơ hồ lặp lại. Một câu trả lời tốt tạo ra một tuyên bố cụ thể, có thể công bố về ai quyết định điều gì — phân biệt chuẩn nền tảng, thiết kế dịch vụ và phê duyệt an toàn lâm sàng — và trung thực về những quyết định nào tổ chức thực sự sẵn lòng phân quyền so với những quyết định nào sẽ giữ ở trung tâm và vì sao.

4. Chúng ta đang tài trợ vận hành và thay đổi một cách trung thực, hay đang lặng lẽ bóp nghẹt việc vận hành dịch vụ đang chạy để trả cho các tính năng mới? Chủ đề nói thẳng rằng bóp nghẹt vận hành để tài trợ thay đổi là cách các hệ thống lâm sàng xuống cấp, và câu hỏi này đưa sự cân bằng ra ánh sáng trước khi một sự cố ngừng hoạt động hoặc sự cố an toàn làm điều đó thay bạn. Nó quan trọng trong y tế và chăm sóc vì "vận hành" không phải là chi phí hậu trường — đó là sự sẵn sàng của các hệ thống mà bác sĩ phụ thuộc vào tại điểm chăm sóc, nên ngân sách vận hành suy giảm biểu hiện thành thời gian ngừng hoạt động có thể ảnh hưởng đến bệnh nhân, chứ không chỉ gây bất tiện cho người dùng. Sự đánh đổi này khó chịu vì thay đổi thì hữu hình và được tán dương trong khi vận hành vô hình cho đến khi nó hỏng, nên hội đồng và lộ trình tự nhiên thiên về cái mới; mô hình "bạn xây, bạn vận hành" giúp giữ vòng phản hồi khép kín, nhưng chỉ khi thời gian vận hành của nhóm được bảo vệ thực sự chứ không chỉ phân bổ trên danh nghĩa rồi bị lấy mất. Hãy làm cho nó cụ thể bằng cách xem tỷ lệ năng lực của mỗi nhóm sản phẩm thực sự dành cho việc giữ dịch vụ an toàn và sẵn sàng quý trước so với kế hoạch, và liệu công việc vận hành có được theo dõi và coi trọng hay bị xem như sự gián đoạn. Một câu trả lời trung thực nêu nơi vận hành hiện đang bị thiếu kinh phí, bảo vệ một phân bổ vận hành thực tế như khoản chi đầu tiên chứ không phải phần còn dư, và thẳng thắn về những dịch vụ đang chạy nào đang mang rủi ro vận hành tích lũy.

5. Chúng ta đang cố ý chọn xây dựng và sở hữu năng lực nào so với mua, và chúng ta có đang vô tình chấp nhận bị khóa chặt đối với dữ liệu lâm sàng cốt lõi không? Thực hành tốt nhất ở đây là quyết định xây hay mua một cách có chủ đích, tránh bị khóa chặt vào một nhà cung cấp duy nhất đối với dữ liệu lâm sàng cốt lõi, và xem nhà cung cấp là một tầng của mô hình vận hành thay vì thứ nằm ngoài nó — câu hỏi này kiểm tra xem những lựa chọn đó có thực sự được đưa ra hay chỉ mặc định xảy ra. Nó quan trọng vì trong y tế số, sự khóa chặt hệ quả nhất xoay quanh hồ sơ lâm sàng và dữ liệu của nó, nơi một kho độc quyền không có lối thoát thực tế có thể giam cả một hệ thống trong một thập kỷ và quyết định mọi dịch vụ phía sau có thể làm gì. Căng thẳng là giữa tốc độ và tính tùy chọn: mua thì nhanh và thường rẻ hơn hôm nay, nhất là với một nhóm đang quá tải, nhưng mỗi lần mua tiện lợi mà không có chuẩn mở hoặc quyền rút lui lặng lẽ thu hẹp lựa chọn của ngày mai, và cái giá chỉ lộ ra khi bạn cố rời đi. Hãy làm cho nó cụ thể bằng cách liệt kê các năng lực cốt lõi của bạn, đánh dấu mỗi cái là chiến lược (tự xây/sở hữu) hay hàng hóa thông dụng (mua), và kiểm tra xem các hợp đồng đằng sau những cái thông dụng có thực sự yêu cầu chuẩn mở (HL7 FHIR, SNOMED CT) và quyền rút lui có hiệu lực thi hành hay không. Một câu trả lời tốt phân biệt vài năng lực thực sự chiến lược với nhiều năng lực có thể mua một cách an toàn, trung thực về nơi tổ chức đã bị khóa chặt về dữ liệu lâm sàng, và cam kết chuẩn mở cùng quyền rút lui trong các hợp đồng quan trọng nhất.

6. Làm sao chúng ta biết khi nào mô hình vận hành cần thay đổi, và những tín hiệu nào sẽ cho chúng ta biết — thay vì tái cơ cấu theo mốt hoặc khi có lãnh đạo mới đến? Chủ đề coi mô hình vận hành là một sản phẩm bạn tiến hóa theo bằng chứng, không phải một sơ đồ đóng khung treo tường, nên câu hỏi này yêu cầu nhóm xác định trước bằng chứng nào sẽ biện minh cho việc định hình lại nó. Nó quan trọng trong y tế và chăm sóc vì tái cơ cấu gây xáo trộn và tốn kém — nó giải tán kiến thức chuyên ngành và an toàn lâm sàng khó khăn mới có — nhưng ngành này dễ bị xáo trộn cấu trúc do chu kỳ chính sách và bổ nhiệm mới hơn là do mô hình hiện tại có thực sự đang cản trở hay không. Căng thẳng là giữa ổn định và thích ứng: đổi mô hình quá dễ dàng thì bạn không bao giờ để các nhóm ổn định hay tích lũy chuyên môn về an toàn, đổi quá hiếm thì các cấu trúc đông cứng bóp nghẹt dòng chảy rất lâu sau khi chúng không còn phù hợp với công việc. Hãy làm cho nó cụ thể bằng cách chọn một tập nhỏ các tín hiệu để theo dõi — dòng chảy công việc, thời gian ra quyết định, việc làm lại và sức khỏe nhóm — và thống nhất sự dịch chuyển nào ở chúng sẽ kích hoạt một cuộc thiết kế lại có chủ đích so với một điều chỉnh nhỏ hơn. Một câu trả lời trung thực cam kết một vài chỉ báo dẫn trước, phân biệt thay đổi dựa trên bằng chứng với màn trình diễn tái cơ cấu, và rõ ràng về ai chịu trách nhiệm kiểm tra mô hình và hành động khi các tín hiệu cho thấy nó đang cản trở việc triển khai.

Trong thực tế: một ví dụ về y tế và chăm sóc#

Một ICS bao gồm năm địa phương có mỗi bệnh viện tự xây các công cụ đặt lịch hẹn dành cho bệnh nhân của riêng mình. Chi phí trùng lặp, trải nghiệm phân kỳ, và không cái nào chia sẻ dữ liệu một cách sạch sẽ. ICS thiết kế lại mô hình vận hành của mình.

Nó xác định ba kết quả (giảm số lần không đến khám, cắt giảm các ca nhập viện có thể tránh, cải thiện công bằng tiếp cận) và các dòng giá trị đằng sau chúng. Nó thành lập một nhóm nền tảng nhỏ sở hữu bốn năng lực khả thi mỏng nhất: một hệ thống danh tính/đăng nhập dùng chung, một lớp tương tác dựa trên FHIR, hạ tầng lưu trữ chung với các mức an toàn cơ sở về bảo mật và lâm sàng, và một hệ thống thiết kế. Mỗi địa phương giữ một nhóm bám dòng giá trị nhưng nay xây dựng trên nền tảng thay vì làm lại từ đầu.

Nguồn tài trợ chuyển từ các gói thầu dự án hằng năm sang ngân sách sản phẩm thường trực cho mỗi dòng giá trị, được giải ngân qua các cổng khám phá/alpha/beta. Một bản đồ RAPID được công bố làm rõ rằng các nhóm địa phương quyết định thiết kế dịch vụ của riêng họ trong các giới hạn của nền tảng và an toàn lâm sàng, trong khi hội đồng số của ICS quyết định các chuẩn nền tảng. Trong vòng một năm, ba địa phương dùng chung một năng lực đặt lịch, mức thiết kế và an toàn cơ sở nhất quán, và những tính năng từng mất một chu kỳ dự án nay được phát hành trong vài tuần — vì nền tảng đã gánh phần việc nặng nhọc không tạo khác biệt.

Góc nhìn theo khu vực#

Một mô hình vận hành được định cỡ theo tổ chức mà nó phục vụ; cùng những tầng đó — dòng giá trị, năng lực, nhóm, quản trị, nền tảng, nhà cung cấp — được vẽ rất khác nhau bởi một công ty khởi nghiệp, một doanh nghiệp lớn và một cơ quan chính phủ.

Công ty khởi nghiệp#

Trong một công ty y tế số nhỏ, mô hình vận hành phần lớn là ngầm định và điều đó không sao: một hoặc hai nhóm bám dòng giá trị, một nhà sáng lập nắm hầu hết quyền ra quyết định, và không có nhóm nền tảng vì chưa có gì để làm nền tảng. Kỷ luật là làm rõ sớm vài quyết định thực sự — xây hay mua kho dữ liệu lâm sàng, cam kết những chuẩn mở nào — để lối tắt hôm nay không trở thành sự khóa chặt ngày mai. Vận hành và thay đổi nằm trong cùng một đôi tay, nên rủi ro là việc giữ cho hệ thống hoạt động cho những khách hàng đầu tiên làm cạn kiệt lộ trình; một sự phân chia thời gian kỹ thuật đơn giản, trung thực là tương đương gọn nhẹ của ngân sách vận hành được bảo vệ. Nhà cung cấp được chọn vì tốc độ, nhưng một công ty khởi nghiệp vẫn nên từ chối bị khóa chặt dữ liệu lâm sàng cốt lõi, vì những người mua NHS tương lai của họ sẽ đòi quyền rút lui.

Doanh nghiệp nhỏ#

Một nhà cung cấp nhỏ đã thành lập — một phòng khám bác sĩ gia đình, một hiệu thuốc cộng đồng, một nhà dưỡng lão hoặc cơ sở chăm sóc tại nhà, một phòng khám đơn lẻ, hoặc một nhà cung cấp công nghệ y tế nhỏ đã qua giai đoạn chưa có doanh thu — có bệnh nhân thật và hoạt động liên tục nhưng không có nhóm nền tảng, không có năng lực số hay CNTT chuyên trách, và ít dư địa về tiền mặt hay nhân sự. Ở đây mô hình vận hành phần lớn là một tập các năng lực mua về được ghép lại với nhau, nên những lựa chọn quyết định là về nhà cung cấp: kiên quyết đòi chuẩn mở và quyền rút lui trong các hệ thống lâm sàng bạn mua sắm, vì bạn gánh cùng các nghĩa vụ về khả năng tương tác và an toàn lâm sàng như một bệnh viện lớn nhưng không có sức mua hay chuyên môn nội bộ của nó. Vận hành và thay đổi dồn về cùng một nhóm ít người vốn còn phải cung cấp dịch vụ chăm sóc, nên kỷ luật trung thực là bảo vệ một chút thời gian để giữ hệ thống an toàn và cập nhật thay vì chỉ chữa cháy. Quyền ra quyết định thì đơn giản — thường là một đối tác hoặc chủ kiêm quản lý quyết định — nhưng điều đó khiến dễ trì hoãn các quyết định số vô thời hạn, nên giá trị là gọi tên vài quyết định quan trọng (hồ sơ lâm sàng nào, nền tảng khu vực dùng chung nào để tham gia) và đưa ra chúng một cách có chủ đích. Khi một ICS hoặc cơ quan quốc gia cung cấp một nền tảng danh tính, tương tác hoặc thiết kế dùng chung, nước đi tốt nhất của doanh nghiệp nhỏ thường là xây dựng trên đó thay vì phát minh lại, mượn năng lực mà họ không thể tự bố trí nhân sự.

Doanh nghiệp lớn#

Một bệnh viện NHS hoặc ICS là nơi hình thái nền tảng cộng liên bang chứng minh giá trị: các tổ chức có chủ quyền phải mang lại cảm giác như một dịch vụ duy nhất với bệnh nhân. Những vấn đề khó khăn mang tính chính trị không kém kỹ thuật — chuyển tiền từ các gói thầu dự án có thời hạn sang ngân sách sản phẩm thường trực, và công bố bản đồ RACI/RAPID để các nhóm địa phương ngừng đẩy lên cấp trên những quyết định thuộc về họ. Một doanh nghiệp công nghệ y tế hoặc dược phẩm lớn có sức mạnh kỹ thuật nền tảng nhưng có nguy cơ xây quá mức một nền tảng nội bộ vĩ đại trở thành điểm nghẽn của chính nó; phép thử nền tảng khả thi mỏng nhất — hai nhóm trở lên rõ ràng cần cùng một thứ — là cái phanh. Ở quy mô này, quyền ra quyết định và dòng chảy tài trợ chính là mô hình vận hành; công nghệ thường không phải là ràng buộc.

Chính phủ#

Một cơ quan công quyền quốc gia hoặc địa phương thiết kế các mô hình vận hành mà các tổ chức khác phải sống trong đó, nên các lựa chọn của nó về chuẩn và nền tảng thực chất là hạ tầng quốc gia. NHS England hoặc DHSC cung cấp một lớp danh tính dùng chung, một trục tương tác hay một hệ thống thiết kế là mẫu hình nền tảng áp dụng ở quy mô dân số, và các kiểm soát chi tiêu cùng cổng đảm bảo theo giai đoạn của nó là cách tiền công được buộc phải giải trình. Kiểu thất bại là một mô hình tập trung trở thành điểm nghẽn xa xôi, áp đặt một giải pháp cho mọi bối cảnh địa phương; cách khắc phục là làm nền tảng cho những năng lực thực sự chung và liên bang hóa phần còn lại cho các bệnh viện và chính quyền địa phương. Trách nhiệm giải trình trước Nghị viện cũng có nghĩa là việc xây hay mua và quản lý nhà cung cấp là vấn đề thuộc hồ sơ công khai, nên chuẩn mở và quyền rút lui không chỉ thận trọng mà còn được kỳ vọng.

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

• Tự động hóa sơ đồ tổ chức. Thiết kế các nhóm quanh các phòng ban hiện có thay vì các dòng giá trị, khiến TOM củng cố các ốc đảo. Giải pháp: thiết kế từ kết quả và dòng giá trị đi xuống.
• Nền tảng trở thành điểm nghẽn. Một nhóm nền tảng trung tâm có phạm vi quá rộng mà mọi yêu cầu phải xếp hàng phía sau. Giải pháp: nền tảng khả thi mỏng nhất, được đối xử như một sản phẩm có SLA.
• Tài trợ dự án cho công việc sản phẩm. Tiền hết hạn buộc phải giải tán rồi dựng lại nhóm. Giải pháp: tài trợ sản phẩm bền vững với các cổng theo giai đoạn.
• Vận hành bị bóp nghẹt để nuôi thay đổi. Thiếu kinh phí cho vận hành dịch vụ đang chạy cho đến khi các hệ thống lâm sàng xuống cấp. Giải pháp: tài trợ vận hành và thay đổi một cách rõ ràng và bảo vệ ngân sách vận hành.
• Quyết định không có chủ. Không ai biết ai quyết định, nên mọi thứ bị đẩy lên. Giải pháp: một RACI/RAPID được công bố.
• Bị khóa chặt theo mặc định. Dữ liệu lâm sàng cốt lõi bị mắc kẹt trong hệ thống độc quyền của nhà cung cấp mà không có lối thoát. Giải pháp: chuẩn mở và quyền rút lui trong mọi hợp đồng chiến lược.

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

Danh sách kiểm tra#

• Mô hình vận hành được thiết kế từ kết quả và dòng giá trị, không phải hệ thống thứ bậc hiện có.
• Các năng lực dùng chung được cung cấp như một nền tảng khả thi mỏng nhất, với các nhóm dòng giá trị xây dựng trên đó.
• Các nhóm sản phẩm được tài trợ bền vững và gắn với các dòng giá trị.
• Kiểm soát chi tiêu theo giai đoạn (các cổng khám phá/alpha/beta/vận hành) và tương xứng với rủi ro và giá trị.
• Quyền ra quyết định được ghi chép (RACI hoặc RAPID) và công bố.
• Vận hành và thay đổi được tài trợ rõ ràng, với ngân sách vận hành được bảo vệ.
• Các loại nhóm (bám dòng giá trị, nền tảng, hỗ trợ, hệ thống con phức tạp) được hiểu và sử dụng.
• Xây/mua là lựa chọn có chủ đích cho từng năng lực; dữ liệu lâm sàng cốt lõi tránh bị khóa chặt.
• Các hợp đồng yêu cầu chuẩn mở (ví dụ HL7 FHIR, SNOMED CT) và quyền rút lui.

Nguồn chính#

• Matthew Skelton & Manuel Pais — Team Topologies (các nhóm bám dòng giá trị, nền tảng, hỗ trợ, hệ thống con phức tạp; nền tảng khả thi mỏng nhất).
• Sổ tay Dịch vụ GOV.UK — kiểm soát chi tiêu và đảm bảo theo giai đoạn (khám phá/alpha/beta/vận hành); Dịch vụ Số của Chính phủ.
• Sổ tay dịch vụ số của NHS — Tiêu chuẩn dịch vụ NHS (service-manual.nhs.uk).
• AXELOS — Management of Portfolios (MoP) và Managing Successful Programmes (MSP) cho quản trị danh mục và chương trình.
• Bain & Company — khung quyền ra quyết định RAPID; và mô hình phân công trách nhiệm RACI.
• John Doerr — Measure What Matters (OKR) để xác định kết quả.

Tài liệu tham khảo#

1. Operating model — Wikipedia — https://en.wikipedia.org/wiki/Operating_model
2. Value stream — Wikipedia — https://en.wikipedia.org/wiki/Value_stream
3. Objectives and key results (OKRs) — Wikipedia — https://en.wikipedia.org/wiki/Objectives_and_key_results
4. Responsibility assignment matrix (RACI) — Wikipedia — https://en.wikipedia.org/wiki/Responsibility_assignment_matrix
5. Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
6. Government Digital Service — Wikipedia — https://en.wikipedia.org/wiki/Government_Digital_Service
7. Fast Healthcare Interoperability Resources (HL7 FHIR) — Wikipedia — https://en.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources
8. SNOMED CT — Wikipedia — https://en.wikipedia.org/wiki/SNOMED_CT
9. Team Topologies: Organizing Business and Technology Teams for Fast Flow — Matthew Skelton & Manuel Pais, IT Revolution — https://teamtopologies.com/book
10. Spend controls and staged assurance (discovery/alpha/beta/live) — GOV.UK Service Manual, Government Digital Service — https://www.gov.uk/service-manual/agile-delivery
11. NHS service standard — NHS digital service manual, NHS England — https://service-manual.nhs.uk/standards-and-technology/service-standard
12. Managing Successful Programmes (MSP) and Management of Portfolios (MoP) — AXELOS/PeopleCert — https://www.axelos.com/
13. Measure What Matters (OKRs) — John Doerr — https://www.whatmatters.com/the-book