Chủ đề 4.1 — Nền tảng và dịch vụ dùng chung

Trong y tế và chăm sóc, một nền tảng dùng chung không phải là tiện lợi tiết kiệm chi phí mà là cách làm cho an toàn, công bằng và niềm tin có thể lặp lại — để mọi nhóm thừa hưởng chúng thay vì phát minh lại, thường là một cách tồi.

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

Khi bạn vận hành triển khai số trên một hệ thống y tế và chăm sóc, bạn nhanh chóng nhận thấy cùng những năng lực bị xây đi xây lại. Mọi dịch vụ đều muốn xác thực một bệnh nhân, tra cứu hồ sơ nhân khẩu, gửi thông báo, ghi dấu vết kiểm toán, hoặc kiểm tra vai trò của một bác sĩ. Nếu để mặc, mỗi nhóm tự xây phiên bản của mình. Bạn có cả chục màn hình đăng nhập, cả chục cách xử lý danh tính bệnh nhân, cả chục nhật ký kiểm toán với chất lượng khác nhau — và cả chục nơi một lỗi an toàn có thể ẩn.

Sự trùng lặp này tốn kém, nhưng vấn đề sâu hơn là nó nguy hiểm và bất bình đẳng. Trong y tế và chăm sóc, hạ tầng mang rủi ro lâm sàng. Nếu logic khớp bệnh nhân của một nhóm yếu hơn nhóm khác, một bệnh nhân có thể bị trao nhầm hồ sơ. Nếu khả năng tiếp cận của một dịch vụ kém hơn, một số người bị loại trừ lặng lẽ. Nếu dấu vết kiểm toán khác nhau, một cuộc điều tra quản trị thông tin bị đình trệ. Một nền tảng dùng chung cho phép bạn xây một năng lực một lần, theo chuẩn cao, với công việc an toàn lâm sàng và khả năng tiếp cận được làm đúng đắn, rồi để nhiều nhóm thừa hưởng chuẩn đó thay vì mỗi nhóm đánh cược việc làm đúng một mình.

Nền tảng cũng định hình nhịp độ của cả hệ thống. Một nền tảng tốt nghĩa là một dịch vụ mới có thể đến với bệnh nhân trong vài tuần thay vì vài năm, vì những phần khó, chung đã tồn tại. Một nền tảng tồi hoặc vắng mặt nghĩa là mọi nhóm gánh toàn bộ sức nặng hạ tầng, và việc triển khai chậm xuống tốc độ của nhóm ít nguồn lực nhất. Trong một lĩnh vực chịu áp lực tài chính và nhân lực kéo dài, nơi cùng những năng lực quốc gia và địa phương được hàng trăm tổ chức cần, làm đúng nền tảng là một trong những quyết định đòn bẩy cao nhất bạn sẽ đưa ra. Chủ đề này nói về cách xây dựng và vận hành chúng tốt — như những sản phẩm có người dùng thật, không phải hạ tầng bắt buộc mà không ai yêu.

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

Một nền tảng, trong bối cảnh này, là một tập năng lực mà các nhóm khác xây trên đó thay vì tự xây. Cách định khung hiện đại hữu ích nhất là một nền tảng là một sản phẩm có người dùng nội bộ. Khách hàng của nó là các lập trình viên, nhóm triển khai và tổ chức đối tác của chính bạn, và thành công của nó được đo như của bất kỳ sản phẩm nào: bằng mức chấp nhận, bằng trải nghiệm của những người dùng nó, và bằng các kết quả nó tạo điều kiện.

Một số ý tưởng liên quan nằm bên dưới. Dịch vụ dùng chung là mô thức tổ chức cũ hơn cung cấp một năng lực một lần cho nhiều bộ phận của một tổ chức thay vì nhân đôi nó ở mỗi bộ phận. Hạ tầng công cộng số mở rộng điều này lên cấp cả một xã hội — các khối xây dựng dùng chung, tái sử dụng được, tương tác được (danh tính, thanh toán, trao đổi dữ liệu) mà các dịch vụ công và tư được xây trên đó. "Chính phủ như một nền tảng", một cụm từ do Tim O'Reilly đặt ra và được các đội chính phủ số khắp nơi tiếp nhận, áp dụng cùng logic cho nhà nước: chính phủ cung cấp các thành phần chung, và các bộ lắp ráp dịch vụ từ chúng thay vì mỗi bộ xây toàn bộ ngăn xếp.

Về mặt kỹ thuật, các nền tảng thường phơi bày năng lực của chúng qua một giao diện lập trình ứng dụng (API) — một hợp đồng xác định cho phép một hệ thống dùng năng lực của hệ thống khác mà không cần biết bên trong của nó. Chúng thường dựa vào các mô hình nền tảng như một dịch vụ (PaaS) trên đám mây, và các nền tảng quốc gia dùng chung thường dựa vào đa thuê bao (multitenancy), nơi một thực thể duy nhất phục vụ nhiều tổ chức trong khi giữ dữ liệu và cấu hình của họ tách biệt.

Ba khái niệm chi phối liệu một nền tảng giúp hay hại. Thứ nhất là tải nhận thức: một nền tảng tốt giảm lượng một nhóm triển khai phải giữ trong đầu, để nhóm có thể tập trung vào vấn đề lâm sàng hay chăm sóc mà nó tồn tại để giải quyết. Thứ hai là "con đường lát sẵn" hay "đường vàng" — một cách mặc định được hỗ trợ tốt, có chính kiến để làm một nhiệm vụ phổ biến mà dễ theo hơn dễ tránh, được cung cấp qua tự phục vụ thay vì gác cổng. Thứ ba là tránh bị khóa chặt vào nhà cung cấp, đó là lý do các nền tảng nên được xây trên chuẩn mở để các tổ chức có thể chuyển giữa các nhà cung cấp mà không có chi phí chuyển đổi cấm đoán.

Trong y tế cụ thể, các dịch vụ dùng chung quốc gia đã là một phần của bức tranh. Các chương trình lịch sử như NHS Connecting for Health đã thiết lập NHS Spine, một tập dịch vụ quốc gia mang dữ liệu cốt lõi như Dịch vụ Nhân khẩu Cá nhân. Các tương đương hiện đại gồm API quốc gia, NHS login cho xác thực công dân, và NHS Notify cho nhắn tin — các năng lực được cung cấp để các dịch vụ riêng lẻ không phải xây lại. Nơi một nền tảng cung cấp cách chung để chứng minh ai đó là ai, nó thường phơi bày đăng nhập một lần để một bác sĩ xác thực một lần thay vì lặp lại. Chủ đề này nói về cách xây dựng và vận hành các nền tảng như vậy; chi tiết về bạn là ai và bạn được làm gì thuộc về Chủ đề 4.2 — Quản lý danh tính và truy cập, và các chuẩn cho phép hệ thống trao đổi dữ liệu thuộc về Chủ đề 4.3 — Khả năng tương tác và chuẩn dữ liệu.

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

1. Xem nền tảng là một sản phẩm, không phải một dự án. Một nền tảng có lộ trình, một quản lý sản phẩm, kinh phí liên tục, và người dùng mà bạn đo sự hài lòng — không phải ngày kết thúc và một cuộc bàn giao. Các dự án kết thúc và phân rã; các nền tảng phải được vận hành vô thời hạn vì các nhóm trở nên phụ thuộc vào chúng. Hãy tài trợ và bố trí nhân sự tương ứng, và xem Chủ đề 5.0 — Công việc dẫn dắt bởi sản phẩm cho kỷ luật vận hành điều này hàm ý.

2. Bắt đầu với nền tảng khả thi mỏng nhất. Xây tập nhỏ nhất các năng lực dùng chung thực sự giải tỏa các nhóm, và chỉ thêm khi nhu cầu và nỗi đau thực biện minh. Ý tưởng "nền tảng khả thi mỏng nhất" này, được giới thiệu trong Chủ đề 1.1 — Mô hình vận hành, bảo vệ chống thất bại phổ biến nhất: một nền tảng trung tâm đầy tham vọng cố làm mọi thứ, đến muộn, và không vừa với ai. Để nền tảng lớn lên từ bằng chứng sử dụng, không phải từ khát vọng kiến trúc.

3. Biến con đường lát sẵn thành con đường dễ. Một nền tảng giành được sự chấp nhận bằng cách làm cho con đường được hỗ trợ nhanh và đơn giản hơn tự xây — qua hướng dẫn ban đầu tự phục vụ, tài liệu rõ ràng, môi trường thử và các mặc định hợp lý có an toàn lâm sàng và khả năng tiếp cận được xây vào. Nếu dùng nền tảng chậm hơn hoặc đau đớn hơn đi vòng nó, các nhóm sẽ đi vòng, và bạn đã tốn tiền để tạo ra một điểm nghẽn. Hãy thiết kế cho giờ đầu tiên của lập trình viên và ngày tệ nhất của họ.

4. Đo thành công bằng mức chấp nhận và trải nghiệm người dùng, không phải sự tồn tại. Các thước đo đúng là bao nhiêu nhóm tự nguyện dùng nền tảng, hướng dẫn ban đầu mất bao lâu, nền tảng sẵn sàng bao nhiêu lần, và người dùng đánh giá trải nghiệm ra sao. Các chỉ số hư danh như số dịch vụ được triển khai không cho bạn biết gì về việc các nhóm có được giúp hay không. Gắn công cụ đo cho nền tảng, thường xuyên nghiên cứu với các nhóm xây trên nó, và xem đường cong chấp nhận giảm hay đình trệ là một vấn đề sản phẩm cần sửa, không phải một vấn đề tuân thủ cần cưỡng chế.

5. Xây trên chuẩn mở và giữ chi phí rút lui rẻ. Ưu tiên các chuẩn và giao diện mở, được áp dụng rộng rãi để cả bạn lẫn các nhóm trên nền tảng của bạn không bị mắc kẹt. Ghi chép cách một nhóm sẽ rời đi, và bảo đảm họ có thể. Nghịch lý là làm cho việc rời đi dễ dàng chính là điều làm các nhóm thoải mái khi đến, và giữ nền tảng trung thực vì nó phải giành chỗ của mình thay vì dựa vào sự bị giam. Điều này giảm trực tiếp sự khóa chặt vào nhà cung cấp khắp hệ thống rộng hơn được thảo luận ở Chủ đề 4.0 — Kiến trúc kỹ thuật, đám mây và hệ thống cũ.

6. Rõ ràng về ai trả và ai quyết định. Một nền tảng dùng chung cần một mô hình kinh phí và một mô hình quản trị được thỏa thuận ngay từ đầu: nó được tài trợ tập trung, tính phí lại cho người dùng, hay lai, và lộ trình của nó được ưu tiên thế nào giữa các bên thuê cạnh tranh. Sự mơ hồ ở đây là điều biến nền tảng thành chiến trường chính trị. Hãy công bố mô hình, trao cho người dùng tiếng nói thực sự trong lộ trình, và xem lại khi nền tảng lớn lên.

7. Vận hành nhóm nền tảng với trách nhiệm và ranh giới rõ ràng. Tổ chức quanh một nhóm nền tảng chuyên trách có nhiệm vụ tạo điều kiện cho các nhóm triển khai bám dòng giá trị qua tự phục vụ, như mô tả trong các mô thức Team Topologies ở Chủ đề 7.0 — Cơ cấu nhóm, vai trò và trách nhiệm. Giữ giao diện giữa nền tảng và người dùng rõ ràng — nền tảng hứa gì, không hứa gì, và cách nhận hỗ trợ — để nền tảng tạo điều kiện thay vì gác cổng.

8. Thiết kế cho đa thuê bao, cô lập và an toàn từ đầu. Nếu nhiều tổ chức sẽ dùng chung một nền tảng, sự tách biệt dữ liệu, cấu hình và miền thất bại của họ là một yêu cầu nền tảng, không phải một tính năng về sau. Trong y tế và chăm sóc đây cũng là yêu cầu quản trị thông tin và an toàn lâm sàng: sự cố của một bên thuê không được phơi bày hay gây nguy hiểm cho bệnh nhân của bên khác. Hãy xây vào sự cô lập, khả năng quan sát theo từng bên thuê, và một hồ sơ an toàn lâm sàng cho chính nền tảng theo DCB0129.

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

1. Nền tảng mỏng nhất nào sẽ thực sự giải tỏa các nhóm của chúng ta, và chúng ta bị cám dỗ xây gì mà lẽ ra không nên? Rất dễ thiết kế một nền tảng bao trùm trên bảng trắng và khó giao một nền tảng mà các nhóm yêu. Hãy bắt đầu từ nỗi đau lặp lại, thực mà các nhóm triển khai của bạn cảm thấy hôm nay — năng lực mà ba nhóm trở lên đang mỗi nhóm xây lại — và cưỡng lại việc thêm bất cứ thứ gì chỉ một nhóm cần hoặc chưa ai yêu cầu. Hỏi năng lực nào thực sự chung so với năng lực nào chỉ trông giống nhau từ xa nhưng khác ở các chi tiết quan trọng về lâm sàng. Hãy cân nhắc cái giá của việc làm sai: một năng lực dùng chung quá sớm mà các nhóm phải xoay xở quanh còn tệ hơn không có nền tảng. Thống nhất một đường rõ ràng giữa điều nền tảng sẽ sở hữu bây giờ và điều nó sẽ cố ý hoãn. Xem lại đường đó theo lịch, chỉ chuyển các mục qua khi nhu cầu và nỗi đau được chứng minh. Kỷ luật là nói không với những ý tưởng hay chưa xứng đáng với chỗ của chúng.

2. Chúng ta sẽ tài trợ nền tảng và quyết định lộ trình của nó như thế nào khi các bên thuê bất đồng? Một nền tảng phục vụ nhiều nhóm với các ưu tiên cạnh tranh, và khoảnh khắc hai bên thuê quan trọng muốn những thứ không tương thích, quản trị của bạn bị thử thách. Hãy quyết định ngay bây giờ nền tảng được tài trợ tập trung, tính phí lại cho người dùng, hay lai, và trung thực về các động cơ mỗi mô hình tạo ra: tính phí lại có thể kìm hãm mức chấp nhận, trong khi tài trợ tập trung có thể tách nền tảng khỏi nhu cầu người dùng. Quyết định ai nắm lộ trình, các bên thuê ảnh hưởng đến nó thế nào, và bạn phân xử giữa nhu cầu khẩn cấp của một tổ chức lớn và nhu cầu cơ bản của một tổ chức nhỏ ra sao. Hãy cân nhắc công bằng một cách rõ ràng, vì mô hình tính phí lại có thể đẩy các tổ chức nhỏ hơn hoặc nghèo hơn ra khỏi các năng lực an toàn dùng chung. Thống nhất cách bạn xử lý một bên thuê muốn tài trợ một tính năng mà những bên khác không muốn. Hãy viết mô hình ra và công bố, để các quyết định cảm giác như quản trị chứ không phải thiên vị. Rồi cam kết xem lại nó khi nền tảng và cơ sở người dùng lớn lên.

3. Làm sao chúng ta biết nền tảng được yêu thích chứ không chỉ bị bắt buộc, và chúng ta sẽ làm gì nếu không? Một nền tảng có thể vững về kỹ thuật, được yêu cầu chính thức, và lặng lẽ bị ghét — và một nền tảng bị bắt buộc nhưng không được yêu tích lũy các cách xoay xở, hệ thống bóng và sự oán giận. Hãy quyết định trước những tín hiệu nào cho bạn biết sự thật: mức chấp nhận tự nguyện nơi các nhóm có lựa chọn, thời gian đến thành công đầu tiên của một nhóm mới, tính sẵn sàng và lịch sử sự cố, và phản hồi trực tiếp từ các lập trình viên dùng nó. Hãy nói về cách bạn thu thập phản hồi trung thực khi bạn cũng nắm quyền lực đối với người dùng của mình, vì người ta ngại chỉ trích một nền tảng họ bị bắt buộc dùng. Thống nhất một đường cong chấp nhận lành mạnh trông thế nào và ngưỡng nào kích hoạt một cuộc nghĩ lại nghiêm túc. Quyết định liệu bạn có bao giờ sẵn lòng cho nghỉ hưu hoặc thay thế nền tảng nếu bằng chứng đòi hỏi. Sẵn lòng nghe rằng nền tảng của bạn không hiệu quả là điều giữ cho nó hiệu quả. Phương án thay thế là chỉ khám phá sự thật khi một dịch vụ lớn đi vòng bạn.

4. Làm sao chúng ta giữ chi phí rút lui rẻ, và một nhóm trên nền tảng của chúng ta có thực sự rời đi được nếu cần không? Rất dễ tuyên bố bạn được xây trên chuẩn mở và khó hơn nhiều là chứng minh một nhóm có thể bỏ đi mà không phải viết lại cấm đoán. Hãy nói thẳng về nơi sự khóa chặt đang len vào — một giao diện độc quyền, một định dạng dữ liệu không được ghi chép, một phụ thuộc quốc gia không có phương án thay thế — và liệu cái giá của việc rời đi có đang lặng lẽ tăng theo thời gian không. Quyết định ai chịu trách nhiệm ghi chép và định kỳ kiểm thử một đường rút lui, thay vì giả định một đường tồn tại. Hãy cân nhắc rằng trong y tế và chăm sóc rủi ro khóa chặt cộng dồn: một nền tảng quốc gia xây trên sự bị giam có thể mắc kẹt cả một hệ thống trong một thế hệ, và những nhóm ít có khả năng hấp thụ chi phí chuyển đổi nhất thường là các nhà cung cấp nhỏ nhất. Một câu trả lời trung thực gọi tên các phụ thuộc cụ thể bạn sẽ khó gỡ, mô tả một lối rút lui cụ thể cho ít nhất một bên thuê thực, và xem tính di động là tính năng bạn duy trì chứ không phải khẩu hiệu bạn lặp lại. Hãy nhớ rằng làm cho việc rời đi dễ dàng thường là điều làm các nhóm thoải mái khi đến.

5. Nền tảng có mang hồ sơ an toàn lâm sàng riêng của nó không, và làm sao chúng ta giữ sự thất bại của một bên thuê khỏi gây hại cho bệnh nhân của bên khác? Khi nhiều tổ chức dùng chung một nền tảng, hạ tầng của nó mang rủi ro lâm sàng thay mặt mọi dịch vụ xây trên nó, nên một lỗi trong khớp bệnh nhân hay rò rỉ giữa các bên thuê không phải vấn đề của một nhóm mà của tất cả. Hãy quyết định liệu nền tảng có hồ sơ an toàn DCB0129 riêng mà các nhóm sử dụng có thể thực sự dựa vào, hay mỗi dịch vụ đang lặng lẽ đánh giá lại cùng một rủi ro dùng chung. Hãy thảo luận cách bạn cô lập dữ liệu, cấu hình và miền thất bại của các bên thuê, và bạn sẽ biết nếu sự cô lập đó bị vi phạm bằng cách nào — khả năng quan sát theo từng bên thuê là sự khác biệt giữa ngăn chặn một sự cố và phát hiện nó muộn. Hãy cân nhắc cả hệ quả quản trị thông tin: một cuộc điều tra về một bên thuê không được đòi hỏi phơi bày hồ sơ của bên khác. Một câu trả lời trung thực có thể chỉ ra một hồ sơ an toàn được duy trì, một ranh giới cô lập đã kiểm thử, và một mô tả rõ ràng về điều nền tảng hứa về an toàn so với điều vẫn là trách nhiệm của từng dịch vụ. Xem an toàn và cô lập là nền tảng, không phải tính năng về sau, là điều cho phép các nhóm thừa hưởng sự đảm bảo thay vì đánh cược.

6. Ranh giới giữa nhóm nền tảng và các nhóm nó phục vụ nằm ở đâu, và làm sao chúng ta ngăn nền tảng trở thành điểm nghẽn? Một nền tảng dùng chung có thể đẩy nhanh mọi nhóm hoặc làm chậm tất cả xuống tốc độ của một hàng đợi trung tâm duy nhất, và sự khác biệt nằm ở mức sắc nét bạn đã vẽ giao diện giữa nền tảng và người dùng. Quyết định nền tảng sở hữu và hứa gì, rõ ràng không làm gì, và một nhóm nhận hỗ trợ thế nào mà không phải chờ một phiếu việc cho công việc thường lệ. Hãy nói về tự phục vụ là mặc định: nếu việc hướng dẫn ban đầu, cấp phát, hay một thay đổi chung đều đòi hỏi nhóm nền tảng hành động bằng tay, bạn đã xây một cổng thay vì một con đường lát sẵn. Hãy cân nhắc thỏa thuận về tải nhận thức ở trung tâm của một nền tảng tốt — nó nên giảm điều một nhóm triển khai phải giữ trong đầu để họ tập trung vào vấn đề lâm sàng, không thêm một tầng để thương lượng. Một câu trả lời trung thực gọi tên các nhiệm vụ vẫn đi qua nhóm nền tảng như một điểm nghẽn, đặt một hướng để biến chúng thành tự phục vụ, và thẳng thắn về nơi nền tảng đang tạo điều kiện so với nơi nó đang gác cổng.

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

Một Hệ thống Chăm sóc Tích hợp (ICS) bao gồm nhiều bệnh viện NHS, nhà cung cấp cộng đồng, và dịch vụ chăm sóc xã hội người lớn của hội đồng hạt liên tục đâm vào cùng một bức tường. Mỗi dịch vụ số mới — một khoa bệnh ảo, một biểu mẫu tự chuyển tuyến cho vật lý trị liệu cộng đồng, một công cụ giám sát nhà dưỡng lão — dành ba tháng đầu xây lại cùng nền móng: chứng minh bệnh nhân là ai, kiểm tra vai trò của chuyên gia, gửi nhắc nhở SMS và viết dấu vết kiểm toán. Việc khớp bệnh nhân của nhóm khoa bệnh ảo hóa ra yếu hơn của nhóm vật lý trị liệu, và một suýt xảy ra diễn ra khi một lời nhắc được gửi nhầm cho người khác. Ban lãnh đạo số của ICS nhận ra mô thức: họ đang trả nhiều lần cho các năng lực lẽ ra chỉ tồn tại một lần, và sự biến thiên là một rủi ro an toàn.

Thay vì ủy thác một nền tảng ICS vĩ đại, họ bắt đầu mỏng. Họ dựng một dịch vụ dùng chung duy nhất làm tốt một việc: nó bọc NHS login và Dịch vụ Nhân khẩu Cá nhân quốc gia sau một API sạch, được ghi chép với một môi trường thử, để bất kỳ nhóm nào cũng có thể xác minh danh tính một công dân và lấy một hồ sơ nhân khẩu đã xác nhận qua một con đường được hỗ trợ. Một nhóm nền tảng nhỏ gồm năm người xem nó như một sản phẩm. Họ công bố một hướng dẫn con đường lát sẵn, cung cấp hướng dẫn ban đầu tự phục vụ, và đặt mục tiêu một nhóm mới nên thực hiện cuộc gọi thành công đầu tiên trong một ngày. Quan trọng là họ không bắt buộc. Họ làm cho nó thành lựa chọn dễ nhất và để nhóm khoa bệnh ảo là người áp dụng sẵn lòng đầu tiên.

Mô hình kinh phí được thỏa thuận công khai: ICS tài trợ tập trung phần lõi của nền tảng trong hai năm đầu để mức chấp nhận không bị kìm hãm bởi tính phí lại, với một cuộc rà soát ở tháng thứ mười tám. Một nhóm liên nhà cung cấp, gồm hội đồng, nắm lộ trình và họp hằng tháng. Khi nhóm vật lý trị liệu đề nghị một năng lực thông báo tiếp theo, nhóm nền tảng thêm một lớp bọc mỏng quanh NHS Notify thay vì xây nhắn tin từ đầu — xây một lần, dùng nhiều lần. Trong vòng một năm, sáu nhóm đã tự nguyện áp dụng dịch vụ danh tính, hướng dẫn ban đầu giảm từ vài tháng xuống vài ngày, và nhóm nền tảng công bố công khai các số liệu về tính sẵn sàng và mức chấp nhận. Khi hệ thống đặt riêng của một bệnh viện đi vòng nền tảng, nhóm xem đó là nghiên cứu thay vì bất tuân, học được ma sát đã thúc đẩy quyết định đó, và sửa nó. Nền tảng lớn lên vì các nhóm chọn nó, và ICS thừa hưởng một cách duy nhất, được kiểm thử tốt, dễ tiếp cận để làm những việc rủi ro, phổ biế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 công nghệ y tế hiếm khi xây nền tảng cho người khác; nó xây trên chúng. Đòn bẩy của bạn đến từ việc tiêu thụ các nền tảng quốc gia và đám mây — NHS login, API quốc gia, các dịch vụ được quản lý của nhà cung cấp đám mây — để nhóm nhỏ của bạn dành năng lượng cho vấn đề lâm sàng, không phát minh lại danh tính hay nhắn tin. Dù vậy hãy để ý sự khóa chặt: chọn chuẩn mở và giữ dữ liệu của bạn di động được, vì năng lực bạn thuê rẻ hôm nay có thể thành phụ thuộc ràng buộc bạn ngày mai. Bên trong, giữ "nền tảng" của riêng bạn mỏng đến mức gần như vô hình; một nhóm hai người không cần một trừu tượng đường vàng, nó cần giao hàng. Kỷ luật là biết khi nào bạn đã lớn đủ để một năng lực nội bộ dùng chung đáng được tách ra.

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 một phòng khám đơn lẻ — hầu như luôn là một bên tiêu thụ nền tảng với ít hoặc không có năng lực số của riêng mình, nên các nền tảng mà nó phụ thuộc thực chất đặt mức sàn an toàn và công bằng của nó. Nhiệm vụ thực tế của bạn là chọn các dịch vụ dùng chung được hỗ trợ thay vì các bản dựng đặt riêng mà bạn không thể bố trí nhân sự hay bảo trì, ưu tiên các năng lực quốc gia như NHS login, tra cứu nhân khẩu và NHS Notify vốn đã mang công việc khả năng tiếp cận và an toàn lâm sàng mà bạn không bao giờ tự tài trợ nổi. Khăng khăng hướng dẫn ban đầu tự phục vụ thực sự và tài liệu rõ ràng, vì bạn không có nhóm nền tảng nào để leo thang và không đủ khả năng chi cho một dự án tích hợp dài. Theo dõi sát mô hình kinh phí: một nền tảng tính phí lại có thể đẩy một nhà cung cấp nhỏ ra khỏi chính các năng lực an toàn mà nó cần nhất, nên hãy đòi tiếp cận công bằng và nêu nó trong bất kỳ quản trị lộ trình nào bạn với tới. Cũng để mắt đến việc rút lui, vì sự khóa chặt vào nhà cung cấp độc quyền khó thoát nhất khi bạn không có nhân viên kỹ thuật nội bộ để di chuyển bạn. Lợi ích là một nền tảng dùng chung tốt cho phép bạn thừa hưởng các chuẩn bạn không thể xây, đáp ứng cùng nghĩa vụ như các tổ chức lớn mà không có nguồn lực của họ.

Doanh nghiệp lớn#

Một bệnh viện lớn hoặc cơ quan quốc gia có quy mô để biện minh các nền tảng thực và bộ máy quan liêu để phá hỏng chúng. Rủi ro là một nhóm nền tảng trung tâm trở thành tháp ngà — thanh lịch về kiến trúc, chậm phản hồi, và tách rời các nhóm triển khai mà nó được cho là phục vụ. Hãy chống lại điều này bằng cách tài trợ nền tảng như các sản phẩm sống lâu với lộ trình và nghiên cứu người dùng riêng, và đo chúng theo mức chấp nhận và trải nghiệm lập trình viên thay vì mức tuân thủ bắt buộc. Đa thuê bao, cô lập và một hồ sơ an toàn lâm sàng cho chính nền tảng trở nên thiết yếu ở quy mô này. Phần thưởng rất lớn: một năng lực được xây một lần theo chuẩn cao và được hàng chục dịch vụ thừa hưởng, nâng mức sàn cho cả tổ chức.

Chính phủ#

Ở cấp quốc gia và hệ thống, khung là hạ tầng công cộng số và chính phủ như một nền tảng: xây các thành phần chung — danh tính, thông báo, tra cứu nhân khẩu, trao đổi dữ liệu — mà hàng trăm tổ chức lắp ráp thành dịch vụ. Rủi ro về tính mở cao nhất ở đây, vì một nền tảng quốc gia xây trên sự khóa chặt độc quyền có thể mắc kẹt cả một hệ thống y tế trong một thế hệ. Quản trị và kinh phí phải được giải quyết công khai, với ảnh hưởng thực cho các tổ chức nhỏ hơn và nghèo hơn mà các nền tảng dùng chung tồn tại một phần để bảo vệ. Cám dỗ bắt buộc mạnh nhất và nguy hiểm nhất ở cấp này; một nền tảng quốc gia bị yêu cầu nhưng không được yêu sinh ra các hệ thống bóng khắp đất nước. Hãy giành sự chấp nhận qua chất lượng và hỗ trợ, và xem mọi cách xoay xở là một tín hiệu để cải thiện.

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

• Điểm nghẽn. Mọi nhóm phải chờ nhóm nền tảng trung tâm làm bất cứ điều gì, nên nền tảng làm chậm triển khai thay vì tăng tốc. Thuốc chữa là tự phục vụ: các nhóm nên có thể hướng dẫn ban đầu và hành động mà không cần phiếu việc.
• Tháp ngà. Nền tảng được thiết kế bởi những người xa triển khai, đáng ngưỡng mộ về kỹ thuật, và không vừa với nhu cầu của nhóm thực nào. Thuốc chữa là vận hành nền tảng như một sản phẩm với nghiên cứu người dùng liên tục.
• Bị bắt buộc nhưng không được yêu. Nền tảng được chính sách yêu cầu nhưng bị đi vòng trong thực tế, tích lũy hệ thống bóng và sự oán giận. Thuốc chữa là giành sự chấp nhận qua chất lượng và lắng nghe khi các nhóm đi vòng bạn.
• Nền tảng mọi thứ. Phạm vi quá tham vọng nghĩa là nền tảng đến muộn, làm quá nhiều, và không làm tốt cái nào. Thuốc chữa là nền tảng khả thi mỏng nhất, lớn lên từ bằng chứng về nhu cầu.
• Khóa chặt bằng lén lút. Nền tảng lặng lẽ buộc các nhóm vào một nhà cung cấp hay giao diện độc quyền, và cái giá của việc rời đi trở nên cấm đoán. Thuốc chữa là chuẩn mở và một đường rút lui được ghi chép, kiểm thử.
• Mơ hồ về kinh phí. Không ai thỏa thuận ai trả hay ai quyết định, nên nền tảng bị bỏ đói hoặc trở thành chiến trường chính trị. Thuốc chữa là một mô hình kinh phí và quản trị rõ ràng, được công bố.
• An toàn như điều nghĩ sau. Nền tảng không có hồ sơ an toàn lâm sàng riêng, nên mọi dịch vụ sử dụng thừa hưởng rủi ro chưa được đánh giá. Thuốc chữa là xem hồ sơ an toàn DCB0129 của nền tảng là nền tảng.

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

Danh sách kiểm tra#

• Nền tảng có một quản lý sản phẩm có tên, một lộ trình, và kinh phí liên tục (không phải dự án).
• Bạn đã bắt đầu từ nền tảng khả thi mỏng nhất và có thể gọi tên điều bạn cố ý hoãn.
• Con đường được hỗ trợ thực sự nhanh và dễ hơn việc các nhóm tự xây.
• Các nhóm mới có thể hướng dẫn ban đầu qua tự phục vụ, với môi trường thử và tài liệu rõ ràng.
• Bạn đo mức chấp nhận, thời gian đến thành công đầu tiên, tính sẵn sàng và trải nghiệm lập trình viên.
• Mô hình kinh phí (tập trung, tính phí lại hay lai) được thỏa thuận và công bố.
• Quản trị lộ trình trao cho các bên thuê, kể cả các tổ chức nhỏ hơn, một tiếng nói thực sự.
• Nền tảng được xây trên chuẩn mở và một đường rút lui được ghi chép tồn tại.
• Cô lập dữ liệu và miền thất bại đa thuê bao được thiết kế vào, không gắn thêm.
• Nền tảng có hồ sơ an toàn lâm sàng riêng (DCB0129) mà các nhóm sử dụng có thể dựa vào.
• Bạn xem các nhóm đi vòng nền tảng là nghiên cứu, không phải bất tuân.

Nguồn chính#

• Sổ tay Dịch vụ GOV.UK và các bài viết của Dịch vụ Số của Chính phủ về chính phủ như một nền tảng và các thành phần chung.
• Matthew Skelton và Manuel Pais, Team Topologies — nhóm nền tảng, nền tảng khả thi mỏng nhất và tải nhận thức.
• Hướng dẫn nhà phát triển và API của NHS England (NHS login, NHS Notify, API quốc gia, và các dịch vụ Spine).
• Các tiêu chuẩn quản lý rủi ro lâm sàng DCB0129 và DCB0160 cho hệ thống CNTT y tế.
• Ngân hàng Thế giới và Liên Hợp Quốc viết về hạ tầng công cộng số và các khối xây dựng công cộng tái sử dụng được.
• Tim O'Reilly, "Government as a Platform", trong Open Government (O'Reilly Media).

Tài liệu tham khảo#

1. Digital public infrastructure — Wikipedia — https://en.wikipedia.org/wiki/Digital_public_infrastructure
2. Shared services — Wikipedia — https://en.wikipedia.org/wiki/Shared_services
3. API (application programming interface) — Wikipedia — https://en.wikipedia.org/wiki/API
4. Platform as a service — Wikipedia — https://en.wikipedia.org/wiki/Platform_as_a_service
5. Multitenancy — Wikipedia — https://en.wikipedia.org/wiki/Multitenancy
6. Cognitive load — Wikipedia — https://en.wikipedia.org/wiki/Cognitive_load
7. Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
8. Open standard — Wikipedia — https://en.wikipedia.org/wiki/Open_standard
9. NHS Connecting for Health (including the NHS Spine and Personal Demographics Service) — Wikipedia — https://en.wikipedia.org/wiki/NHS_Connecting_for_Health
10. Single sign-on — Wikipedia — https://en.wikipedia.org/wiki/Single_sign-on
11. Team Topologies: Organizing Business and Technology Teams for Fast Flow — Matthew Skelton and Manuel Pais (IT Revolution Press) — https://teamtopologies.com/book
12. Government as a Platform — Tim O'Reilly, in Open Government (O'Reilly Media) — https://www.oreilly.com/library/view/open-government/9781449381936/ch02.html
13. GOV.UK Service Manual — Government Digital Service — https://www.gov.uk/service-manual
14. NHS login and NHS England developer/API guidance — NHS England — https://digital.nhs.uk/services/nhs-login
15. Clinical risk management: its application in the manufacture of health IT systems (DCB0129) — NHS England — https://digital.nhs.uk/services/clinical-safety/documentation