Chủ đề 10.3 — Quản lý tri thức và tài liệu

Tóm lại trong một câu: Trong một dịch vụ trọng yếu về an toàn, điều các nhóm của bạn biết nhưng chưa bao giờ viết ra là một rủi ro lâm sàng, không chỉ là sự bất tiện — nên hãy xem tài liệu là sản phẩm bàn giao hạng nhất và sự liên tục của tri thức là một nghĩa vụ, không phải một điều tốt đẹp thêm vào.

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

Các nhóm y tế số nhỏ, chuyên biệt, và thường được ghép từ nhân viên chính thức, nhà thầu và kỹ sư của nhà cung cấp. Người hiểu vì sao giao diện giải phẫu bệnh thử lại ba lần trước khi thất bại, hoặc cờ nào trong hồ sơ bệnh nhân điện tử chặn một cảnh báo dị ứng trùng lặp, thường là một cá nhân duy nhất — và cá nhân đó chuyển đi, nghỉ hưu, hay ốm đúng tuần tích hợp hỏng lúc 2 giờ sáng. Khi tri thức rời đi cùng họ, hệ thống không chỉ trở nên khó bảo trì hơn; nó trở nên khó vận hành an toàn hơn. Một cách lách không được ghi lại mà một bác sĩ dựa vào có thể lặng lẽ biến mất, và không ai còn lại biết nó từng chịu lực.

Mức cược đặc thù cho ngành. Một cấu hình bị hiểu sai có thể tạo ra hồ sơ sai bệnh nhân, một cảnh báo bị bỏ sót, hay một giấy giới thiệu hỏng — những tác hại đo bằng kết quả bệnh nhân, không phải phiếu ngừng hoạt động. Các cơ quan công cũng mang nghĩa vụ luật định: hồ sơ y tế phải được lưu trong các khoảng thời gian xác định, và quyết định về chăm sóc và tiền công phải kiểm toán được nhiều năm sau và tìm thấy được khi một pháp y, một cơ quan quản lý hay một yêu cầu Tự do Thông tin ập đến. Quản lý tri thức tốt vì thế một phần là an toàn lâm sàng, một phần là quản trị, và một phần là sự tôn trọng người kế tiếp phải giữ dịch vụ chạy. Nó không thể tách rời cách bạn vận hành hoạt động trực tiếp (xem Chủ đề 3.8 — Quản lý dịch vụ và vận hành trực tiếp) và cách bạn thiết kế các nhóm (xem Chủ đề 7.0 — Cơ cấu nhóm, vai trò và trách nhiệm, vai trò và trách nhiệm).

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

Quản lý tri thức như một kỷ luật. Quản lý tri thức là tập hợp các thực hành qua đó một tổ chức tạo ra, nắm bắt, chia sẻ và tái sử dụng điều nó biết. Nó cân bằng ba thành phần — con người và văn hóa, quy trình và cấu trúc, và công nghệ — và thất bại bất cứ khi nào lãnh đạo xem nó là một vụ mua công cụ thay vì một thói quen. "Tri thức" trải từ cách một lộ trình lâm sàng thực sự hoạt động trong một quỹ cụ thể đến cách một động cơ tích hợp cụ thể được cấu hình.

Tri thức ẩn so với tri thức tường minh. Tri thức ẩn là cái sống trong đầu và tay con người — phán đoán, trực giác, và "bạn phải biết quỹ này mã hóa xuất viện khác" khó viết ra. Tri thức tường minh là cái đã được diễn đạt và hệ thống hóa thành tài liệu, sơ đồ và sổ tay vận hành. Phần lớn tri thức giữ cho một dịch vụ an toàn bắt đầu là ẩn; công việc của quản lý tri thức là chuyển đủ nhiều thành dạng tường minh để dịch vụ không phụ thuộc vào bất kỳ cái đầu nào.

Mô hình chuyển đổi tri thức SECI. Mô hình SECI (Xã hội hóa, Ngoại hiện hóa, Kết hợp, Nội hiện hóa), của Nonaka và Takeuchi, mô tả cách tri thức di chuyển giữa dạng ẩn và tường minh: chia sẻ bằng cách làm việc cạnh nhau (xã hội hóa), viết tri thức ẩn ra (ngoại hiện hóa), kết hợp các mảnh tường minh thành tài liệu lớn hơn (kết hợp), và hấp thụ tri thức đã ghi lại trở lại thực hành trôi chảy (nội hiện hóa). Nó hữu ích vì nhắc bạn rằng tài liệu riêng không đủ — làm việc theo cặp, theo dõi người khác làm và các cộng đồng quan trọng không kém wiki.

Phụ thuộc người then chốt và hệ số xe buýt. Hệ số xe buýt là số người phải mất đi trước khi một dịch vụ đình trệ vì thiếu ai đó hiểu nó. Hệ số xe buýt bằng một là trạng thái mặc định của hầu hết nhóm số nhỏ và là rủi ro vận hành nghiêm trọng trong một dịch vụ mà sức khỏe con người phụ thuộc. Luân chuyển nhân viên cao, dùng nhiều nhà thầu và khóa chặt một nhà cung cấp đều kéo con số xuống; tài liệu có chủ đích, đào tạo chéo và làm việc theo cặp kéo nó lên lại.

Tài liệu như sản phẩm bàn giao hạng nhất. Xem tài liệu là sản phẩm, không phải sản phẩm phụ. Một sổ tay dịch vụ mô tả dịch vụ là gì và hành xử thế nào; một sổ tay vận hành (hay playbook) đưa ra các quy trình từng bước để khởi động, dừng và khôi phục nó; một bản ghi quyết định kiến trúc (ADR) nắm bắt vì sao một lựa chọn quan trọng được đưa ra, để những người bảo trì tương lai không gỡ nó khi không biết lý do. Một nguồn sự thật duy nhất nghĩa là mỗi sự kiện được làm gốc ở đúng một nơi, để người ta không đuổi theo các bản sao mâu thuẫn của "kiến trúc hiện tại".

Tài liệu như mã. Giữ tài liệu trong cùng kho kiểm soát phiên bản với công việc — viết bằng văn bản thuần hay Markdown, rà soát như mã, xuất bản tự động — giữ tài liệu gần thứ chúng mô tả và có nhiều khả năng cập nhật hơn hẳn. Khi sơ đồ sống cạnh mã và đổi trong cùng một pull request, nó mục chậm hơn.

Cộng đồng thực hành. Một cộng đồng thực hành (đôi khi gọi là guild) là một nhóm xuyên các đội cùng chia sẻ một nghề — cán bộ an toàn lâm sàng, kỹ sư front-end, trưởng quản trị thông tin — và cùng nhau cải thiện nó. Cộng đồng thực hành lan truyền tri thức ẩn theo chiều ngang qua một tổ chức mà ranh giới nhóm theo chiều dọc sẽ nhốt lại.

Quản lý hồ sơ và lưu giữ. Quản lý hồ sơ điều chỉnh thông tin qua vòng đời của nó, gồm phải giữ bao lâu và khi nào được hủy. Trong y tế điều này một phần là luật định: hồ sơ lâm sàng mang thời hạn lưu giữ xác định theo Quy tắc Thực hành Quản lý Hồ sơ NHS. Điều này khác với tài liệu nhóm, và nhầm lẫn hai thứ gây ra lỗi thật — một điểm chúng ta quay lại bên dưới.

Kiến trúc thông tin và khả năng tìm thấy. Kiến trúc thông tin là thiết kế cấu trúc của một không gian thông tin để người ta tìm được cái họ cần. Một wiki mười nghìn trang không có cấu trúc không phải tài liệu; nó là bãi rác. Khả năng tìm thấy là khác biệt giữa tri thức tồn tại và tri thức được dùng.

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

1. Biến tài liệu thành một phần của định nghĩa hoàn thành, không phải nghĩ sau. Một tính năng, tích hợp hay thay đổi cấu hình không "xong" cho đến khi mục sổ tay vận hành, ADR của nó (nếu một quyết định quan trọng được đưa ra) và bản cập nhật sổ tay dịch vụ tồn tại. Nhúng điều này vào cách làm việc của bạn để nó được viết khi tri thức còn mới, bởi người đang có nó. Ghi tài liệu hồi tố cho một hệ thống sáu tháng sau, từ trí nhớ, là nơi sinh ra sai sót và khoảng trống nguy hiểm.

2. Giữ một nguồn sự thật duy nhất và liên kết ra ngoài từ nó. Quyết định, theo từng miền, phiên bản có thẩm quyền của mỗi sự kiện sống ở đâu — kiến trúc, lịch trực, sơ đồ luồng dữ liệu — và làm mọi thứ khác trỏ tới nó thay vì sao chép. Tài liệu trùng lặp trôi dạt, và trong bối cảnh lâm sàng một bản sao cũ nói "kiểm tra dị ứng đang bật" khi nó tắt còn tệ hơn không có tài liệu. Xóa không thương tiếc hoặc chuyển hướng các bản trùng lặp cũ bạn đã có.

3. Áp dụng tài liệu như mã và giữ tài liệu cạnh công việc. Lưu sổ tay vận hành, ADR và sổ tay dịch vụ trong kiểm soát phiên bản bên cạnh các hệ thống chúng mô tả, rà soát thay đổi tài liệu trong cùng pull request với thay đổi mã, và xuất bản tự động. Điều này làm cập nhật rẻ, thay đổi rà soát được, và lịch sử kiểm toán được — và nó nghĩa là người thay đổi hệ thống được nhắc đổi tài liệu trong cùng hơi thở.

4. Viết sổ tay vận hành mà một người lạ đang căng thẳng có thể làm theo lúc 3 giờ sáng. Một sổ tay vận hành nên giả định người đọc mệt, không quen hệ thống, và chịu áp lực — vì trong một sự cố lớn họ sẽ như vậy. Dùng các bước đánh số, theo nghĩa đen, gọi tên chính xác màn hình và lệnh, và nêu kết quả mong đợi của mỗi bước và phải làm gì nếu nó thất bại. Kiểm thử chúng bằng cách nhờ người không viết chúng thực hiện một lần khôi phục trong buổi diễn tập.

5. Nắm bắt "vì sao", không chỉ "cái gì", bằng bản ghi quyết định kiến trúc. Một ADR ngắn — bối cảnh, quyết định, hệ quả — bảo toàn lập luận đằng sau các lựa chọn quan trọng để người bảo trì tương lai không đảo ngược một quyết định mà không hiểu ràng buộc đã thúc đẩy nó. Trong y tế điều này đặc biệt quan trọng: một cấu hình trông lạ có thể tồn tại vì một phân tích mối nguy an toàn lâm sàng hay một phán quyết quản trị thông tin. Ghi lại lý do ngăn một cuộc "dọn dẹp" thiện chí đưa trở lại một rủi ro đã biết.

6. Chủ đích nâng hệ số xe buýt trên mọi hệ thống trọng yếu. Xác định các hệ thống có hệ số xe buýt bằng một và xem đó là rủi ro trên sổ đăng ký của bạn với người sở hữu có tên và kế hoạch. Ghép cặp người, luân phiên tri thức trực, chạy các buổi "teach-back" nơi chuyên gia ghi tài liệu trong khi đồng nghiệp theo dõi, và cấm bất kỳ cá nhân nào là người duy nhất có thể triển khai hay khôi phục một dịch vụ trọng yếu về an toàn. Điều này rẻ hơn việc phát hiện khoảng trống trong lúc ngừng hoạt động.

7. Chạy các buổi rà soát sau sự cố thay đổi thực hành, không đổ lỗi cho người. Sau bất kỳ sự cố quan trọng nào, chạy một rà soát sau sự cố không đổ lỗi tạo ra các hành động có tài liệu, có chủ, có thời hạn — và rồi thực sự đóng chúng. Bài học được lưu hồ sơ và không bao giờ xem lại là màn kịch; phép thử của quy trình là liệu một sự cố sau có cùng hình dạng có được ngăn không. Đưa phát hiện thẳng trở lại sổ tay vận hành và hồ sơ an toàn lâm sàng (xem Chủ đề 3.8 — Quản lý dịch vụ và vận hành trực tiếp).

8. Đầu tư vào kiến trúc thông tin và khả năng tìm thấy. Cấu trúc cơ sở tri thức của bạn để người mới tìm được sổ tay vận hành trực trong dưới một phút, và tỉa mạnh tay — một trang lỗi thời là một khoản nợ, không phải tài sản. Thỏa thuận quy ước đặt tên, một thứ bậc rõ ràng, và một người sở hữu cho mỗi khu vực, và đặt ngày "rà soát lần cuối" trên các trang quan trọng để người đọc đánh giá được độ mới. Tìm kiếm không thay thế cấu trúc; nó bổ sung cho cấu trúc.

9. Nuôi dưỡng cộng đồng thực hành để lan truyền tri thức ẩn. Lập các guild xuyên nhóm cho những nghề quan trọng — an toàn lâm sàng, bảo mật, front-end, kỹ thuật dữ liệu — với nhiệm vụ nhẹ: chia sẻ điều bạn đang học, thỏa thuận mô thức chung, cố vấn người mới. Các diễn đàn này chuyển tri thức ẩn mà không tài liệu nào nắm được, và chúng giảm sai lầm trùng lặp giữa các nhóm (xem Chủ đề 7.5 — Phát triển con người và tổ chức). Hãy cho chúng thời gian trong tuần làm việc, nếu không chúng héo.

10. Tách tài liệu nhóm khỏi hồ sơ luật định — và quản lý cả hai. Rõ ràng về cái gì là tri thức nhóm (sổ tay vận hành, ADR, wiki) so với cái gì là hồ sơ chịu lưu giữ theo luật (hồ sơ lâm sàng, quyết định chăm sóc, phê duyệt tài chính, quyết định quản trị thông tin). Áp dụng lịch lưu giữ của Quy tắc Thực hành Quản lý Hồ sơ NHS cho loại sau, và đừng để việc xóa wiki tùy tiện hủy thứ bạn bị pháp luật yêu cầu giữ. Tương tự, đừng tích trữ mọi thứ mãi mãi "cho chắc" — lưu giữ quá mức tự nó là rủi ro quản trị và bảo vệ dữ liệu.

11. Biến việc tiếp nhận nhân viên mới thành phép thử cho tài liệu của bạn. Xem mỗi lần tiếp nhận là một cuộc kiểm toán sống: nếu một kỹ sư hay bác sĩ mới có năng lực không thể làm việc hiệu quả từ tài liệu viết của bạn cộng một chút làm việc theo cặp, tài liệu của bạn đã thất bại, và những khoảng trống họ gặp là backlog của bạn. Nhờ người mới sửa điều đầu tiên làm họ bối rối như đóng góp đầu tiên của họ. Điều này biến tiếp nhận từ chi phí một chiều thành vòng cải tiến liên tục cho sự liên tục tri thức.

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

1. Nếu người duy nhất hiểu tích hợp trọng yếu nhất của chúng ta rời đi ngày mai, mất bao lâu chúng ta bị phơi bày — và cụ thể chúng ta sẽ không biết điều gì? Câu hỏi này biến ý niệm trừu tượng về hệ số xe buýt thành một bài kiểm tra áp lực cụ thể cho các hệ thống quan trọng nhất của bạn. Đi qua một ví dụ thực — nguồn dữ liệu giải phẫu bệnh, cấu hình đăng nhập một lần, logic đối sánh của hồ sơ chăm sóc chung — và hỏi trung thực ai khác có thể vận hành, thay đổi và khôi phục nó mà không có người đó. Căng thẳng cần làm lộ là tri thức sâu nhất thường nằm ở cá nhân bận rộn nhất, đáng tin nhất của bạn, và áp lực triển khai khiến việc họ không bao giờ dừng lại để viết ra là hợp lý. Phân biệt tri thức thực sự ẩn và khó hệ thống hóa với tri thức chỉ đơn giản chưa bao giờ được nắm bắt vì không ai dành thời gian. Một câu trả lời tốt, trung thực gọi tên to các hệ thống có hệ số xe buýt bằng một của bạn, thừa nhận khoảng trống nào là thật, và đưa ra một kế hoạch có tính chi phí — làm việc theo cặp, các đợt chạy nước rút tài liệu, đào tạo chéo — thay vì một lời trấn an mơ hồ rằng "tất cả nằm trong đầu mọi người và thế là ổn". Nếu cuộc trò chuyện dễ chịu, bạn chưa đủ cụ thể.

2. Khi chúng ta viết điều gì đó ra, làm sao biết có ai tìm thấy, tin và giữ nó cập nhật — và tài liệu của chúng ta đã nói dối chúng ta ở đâu? Tài liệu lỗi thời không trung lập; trong môi trường trọng yếu về an toàn nó chủ động dẫn một người vận hành đang căng thẳng đến hành động sai. Cuộc thảo luận nên đối mặt với khác biệt giữa có tài liệu và có tài liệu người ta có thể tìm, tin và hành động — một câu hỏi về kiến trúc thông tin, quyền sở hữu và độ mới, không phải khối lượng. Tranh luận liệu cơ sở tri thức của bạn có cấu trúc thực hay đã thành một mớ mà không ai điều hướng, và liệu tài liệu có sống đủ gần công việc (tài liệu như mã) để giữ cập nhật hay trôi dạt trong một công cụ riêng không ai cập nhật. Hỏi mỗi người lần cuối họ dựa vào một tài liệu nội bộ và thấy nó sai là khi nào, và điều đó tốn gì. Một câu trả lời mạnh xác định các trang cụ thể bạn biết là cũ, gán người sở hữu và ngày rà soát, và thỏa thuận một nguồn sự thật duy nhất cho những sự kiện quan trọng nhất — và sẵn lòng xóa nhiều hơn thêm.

3. Sau sự cố nghiêm trọng gần nhất của chúng ta, cái gì thực sự đã đổi trong cách chúng ta làm việc — và nếu câu trả lời là "không nhiều", vì sao chúng ta cứ chạy các buổi rà soát? Rà soát sau sự cố phổ biến; rà soát thay đổi thực hành thì hiếm, và khoảng cách giữa hai loại là nơi những thất bại tương tự tái diễn. Điều này kiểm tra liệu quy trình rút bài học của bạn là một vòng phản hồi thực hay một nghi thức tạo ra tài liệu mà không đổi gì. Khám phá trung thực các điều kiện văn hóa: rà soát chỉ lộ sự thật nếu chúng không đổ lỗi, và người ta sẽ giấu nguyên nhân thực nếu quy trình trừng phạt họ, nên an toàn tâm lý là điều kiện tiên quyết, không phải điều tốt đẹp (xem Chủ đề 8.1 — Quản lý thay đổi). Nhìn vài sự cố gần nhất của bạn và truy từng hành động xem nó có hoàn thành không và có ngăn được tái diễn không. Một câu trả lời tốt chỉ ra được một thay đổi cụ thể — một sổ tay vận hành được viết lại, một cảnh báo mới, một sửa thiết kế — mà một buổi rà soát trước đã tạo ra, và thẳng thắn về các hành động được ghi rồi lặng lẽ bị bỏ, với kế hoạch khép vòng đó.

4. Cái nào chúng ta nắm giữ là hồ sơ luật định chúng ta bị pháp luật buộc giữ, cái nào là ghi chú làm việc chúng ta quản lý theo độ mới — và chúng ta có tự tin mình không xóa loại đầu hay tích trữ loại sau? Các tổ chức y tế và chăm sóc mang nghĩa vụ lưu giữ mà hầu hết nhóm số xử lý theo bản năng thay vì theo quy tắc, và sai theo cả hai hướng đều có thật: tùy tiện xóa một trang wiki hóa ra ghi lại một quyết định chăm sóc, hoặc tích trữ mọi thứ mãi mãi "cho chắc" và tạo ra khoản nợ bảo vệ dữ liệu và khả năng tìm thấy. Cuộc thảo luận nên buộc vạch một đường rõ ràng giữa một hồ sơ chịu Quy tắc Thực hành Quản lý Hồ sơ NHS — hồ sơ lâm sàng, quyết định chăm sóc và kinh phí, phán quyết quản trị thông tin — và tri thức nhóm như sổ tay vận hành và ADR bạn quản lý theo độ mới, không phải lưu giữ pháp lý. Làm lộ các trường hợp giữa khó xử, như một ADR ghi lại vì sao một mối nguy an toàn lâm sàng được chấp nhận, có thể là cả hai. Căng thẳng là kỹ sư tối ưu cho tài liệu gọn gàng, hiện hành trong khi quản trị tối ưu cho lưu giữ bảo vệ được, và hai bản năng kéo ngược chiều. Một câu trả lời trung thực nói được ai sở hữu lịch lưu giữ, ranh giới được vạch ở đâu, và điều gì sẽ xảy ra với một hồ sơ cụ thể nếu nó bị một pháp y, một cơ quan quản lý hay một yêu cầu Tự do Thông tin đòi nhiều năm sau.

5. Cái gì trong cách làm việc của chúng ta thực sự khiến tài liệu được viết khi tri thức còn mới — và chúng ta vẫn dựa vào thiện chí và ý định tốt ở đâu? Mọi nhóm đều đồng ý tài liệu quan trọng; ít nhóm hơn nhiều có cơ chế khiến nó xảy ra theo mặc định thay vì bằng hành động anh hùng. Câu hỏi này thăm dò liệu việc viết ra có được kỹ thuật hóa vào dòng công việc — một định nghĩa hoàn thành chặn "xong" nếu thiếu mục sổ tay vận hành hay ADR, tài liệu được rà soát trong cùng pull request với thay đổi, tài liệu như mã để sơ đồ sống cạnh thứ nó mô tả — hay nó phụ thuộc vào việc cá nhân chọn dừng lại và viết khi áp lực triển khai bảo phát hành. Xem xét trung thực các khuyến khích: ghi tài liệu hồi tố cho một hệ thống từ trí nhớ sáu tháng sau là nơi sinh ra những sai sót nguy hiểm, nên giá trị gần như hoàn toàn nằm ở việc nắm bắt nó ngay lúc đó. Nhìn vài thay đổi gần nhất của bạn và hỏi tài liệu được viết bởi người nắm tri thức, vào lúc đó, hay được gắn thêm sau bởi người dựng lại. Một câu trả lời mạnh chỉ ra các cơ chế cụ thể đã có và gọi tên các khoảng trống nơi quy trình vẫn dựa vào trí nhớ và ý chí, với kế hoạch khép lại.

6. Chúng ta chuyển tri thức mà không tài liệu nào bao giờ nắm bắt được — phán đoán và "bạn phải biết quỹ này mã hóa xuất viện khác" — thế nào, và điều đó có khó hơn mỗi khi hợp đồng của một nhà thầu kết thúc không? Phần lớn điều giữ cho một dịch vụ an toàn là ẩn: trực giác, nhận dạng mô thức và bối cảnh khó giành được mà chống lại việc bị viết ra, và mô hình SECI nhắc nhở rằng tài liệu riêng không bao giờ ngoại hiện hóa hoàn toàn nó. Câu hỏi này hỏi bạn lan truyền tri thức đó một cách có chủ đích qua làm việc theo cặp, theo dõi người khác làm, các buổi teach-back và cộng đồng thực hành đến đâu, thay vì giả định wiki làm việc đó. Căng thẳng sắc nhất nơi bạn dựa vào nhà thầu và nhiều nhà cung cấp, vì tri thức sâu nhất của họ bước ra cửa vào cuối mỗi hợp đồng trừ khi việc nắm bắt là kỳ vọng hợp đồng và văn hóa, không phải một ân huệ nhờ vào tuần cuối. Thảo luận liệu các nghề của bạn — an toàn lâm sàng, tích hợp, kỹ thuật dữ liệu — có các guild sống với thời gian được bảo vệ, hay học hỏi xuyên nhóm chỉ xảy ra tình cờ. Một câu trả lời trung thực phân biệt tri thức thực sự ẩn cần chuyển từ người sang người với tri thức chỉ đơn giản chưa được nắm bắt, và chỉ ra được các thực hành thực — một lịch làm việc theo cặp, một kế hoạch liên tục tri thức cho nhà thầu sắp rời đi, một cộng đồng thực hành đang hoạt động — thay vì một khát vọ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) vận hành một hồ sơ chăm sóc chung lấy dữ liệu từ ba quỹ cấp cứu, các dịch vụ cộng đồng và một hệ thống quản lý ca chăm sóc xã hội. Tích hợp được xây hai năm trước chủ yếu bởi một kỹ sư hợp đồng, "Dev", người hiểu mọi đặc thù của logic đối sánh quyết định khi nào hai hồ sơ chỉ cùng một người. Hợp đồng của Dev kết thúc sau sáu tuần. Có một wiki, nhưng lần cập nhật có ý nghĩa cuối cùng là trong lúc xây.

Trưởng bộ phận triển khai xem đây là rủi ro hệ số xe buýt bằng một và đưa nó vào sổ đăng ký rủi ro chương trình với tên chính bà bên cạnh. Trong sáu tuần, bà tài trợ một nỗ lực "liên tục tri thức" nhỏ: Dev làm việc theo cặp mỗi sáng với hai kỹ sư chính thức, và thay vì một buổi đổ hết đầu lúc chia tay họ ngoại hiện hóa dần khi làm — viết sổ tay vận hành cho các kiểu hỏng Dev thuộc lòng, và ADR giải thích vì sao logic đối sánh dung thứ một số sai lệch nhất định (hóa ra một quy tắc trông cẩu thả tồn tại để tránh một mối nguy an toàn bệnh nhân đã biết được đánh dấu trong hồ sơ an toàn lâm sàng ban đầu). Tài liệu vào cùng kho Git với mã tích hợp, được rà soát trong pull request, nên có phiên bản và hiện hành.

Hai tháng sau khi Dev rời đi, nguồn dữ liệu từ một quỹ cấp cứu bắt đầu tạo hồ sơ bệnh nhân trùng lặp qua đêm. Kỹ sư trực — người chưa bao giờ gặp Dev — mở sổ tay vận hành, làm theo các bước đánh số, xác nhận kết quả mong đợi ở mỗi giai đoạn, và khôi phục đối sánh đúng trong vòng một giờ. Trong buổi rà soát sau sự cố không đổ lỗi, nhóm tìm ra nguyên nhân kích hoạt (một thay đổi thượng nguồn về cách quỹ mã hóa số NHS) và biến nó thành một cảnh báo giám sát và một bản cập nhật sổ tay vận hành. Điều lẽ ra là một cuộc chạy loạn nhiều ngày, rủi ro cao — và một sự cố an toàn bệnh nhân thực sự — đã thành một lần khôi phục một giờ có tài liệu, vì tri thức ẩn đã được làm thành tường minh khi người nắm giữ nó còn ở đó.

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

Công ty khởi nghiệp#

Một công ty y tế số khởi nghiệp sống với rủi ro hệ số xe buýt cao nhất và ít dư địa nhất để giải quyết nó: một nhúm kỹ sư, tri thức sâu trong mỗi cái đầu, và một văn hóa coi trọng phát hành hơn viết. Bước đi thực dụng là tài liệu nhẹ, rẻ nhúng vào quy trình — ADR là các tệp Markdown ngắn trong kho, sổ tay vận hành viết lần đầu có gì đó hỏng, tài liệu như mã từ ngày đầu để thói quen hình thành trước khi quy mô làm nó khó. Người sáng lập nên chống cám dỗ hoãn mọi tài liệu cho đến "sau khi đạt product-market fit", vì một lần ngừng hoạt động trong sản phẩm lâm sàng, hay một đánh giá an toàn lâm sàng hoặc DTAC (Tiêu chí Đánh giá Công nghệ Số) thất bại vì thiếu bằng chứng, có thể là sinh tử. Mục tiêu không phải một cơ sở tri thức bóng bẩy mà là bảo đảm không một sự ra đi nào có thể làm chìm công ty.

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, hay một phòng khám đơn lẻ — mang cùng nghĩa vụ an toàn lâm sàng và lưu giữ hồ sơ như một quỹ lớn nhưng không có chức năng CNTT hay quản lý tri thức chuyên trách và ít dư địa để xây. Ở đây thực hành phải tương xứng triệt để: một nơi tìm thấy được cho nhúm sổ tay vận hành quan trọng (cách khôi phục hệ thống lâm sàng, gọi ai khi hồ sơ chăm sóc chung hỏng), một sắp xếp người sở hữu có tên đơn giản để tri thức trọng yếu không chỉ nằm ở quản lý phòng khám hay một điều dưỡng lâu năm, và một đường rõ ràng giữa hồ sơ luật định họ bị pháp luật buộc giữ và ghi chú làm việc họ không bị buộc. Rủi ro cấp tính là một hệ số xe buýt bằng một cải trang thành sự liên tục: người biết mọi thứ được cấu hình thế nào cũng là người đang điều hành hằng ngày, và một lần nghỉ hưu hay ốm dài có thể để lại không ai vận hành được một hệ thống trọng yếu về an toàn. Nơi hệ thống do nhà cung cấp cấp và lưu trữ, nhà cung cấp nhỏ vẫn nên viết ra cấu hình địa phương và cách lách của chính mình, vì nhà cung cấp sẽ không ghi lại tổ chức này thực sự dùng sản phẩm thế nào.

Doanh nghiệp lớn#

Một quỹ NHS lớn, ICS hay nhà cung cấp công nghệ y tế đối mặt với thất bại ngược lại: quá nhiều tài liệu, rải khắp SharePoint, Confluence, ổ mạng và email, không có nguồn sự thật duy nhất và khả năng tìm thấy kém. Thách thức của doanh nghiệp lớn là kiến trúc thông tin, quyền sở hữu và tỉa bớt — quyết định mỗi sự kiện được làm gốc ở đâu, gán người sở hữu, ngừng các bản trùng lặp, và nối quản lý tri thức với quản lý dịch vụ và kiểm soát thay đổi. Cộng đồng thực hành xứng đáng chỗ đứng ở đây, lan truyền mô thức qua hàng chục nhóm vốn mỗi nhóm sẽ học cùng một bài học một cách đau đớn. Rủi ro cần quản lý là dùng nhiều nhà thầu và nhà cung cấp, nơi tri thức bước ra cửa vào cuối mỗi hợp đồng trừ khi việc nắm bắt là kỳ vọng hợp đồng và văn hóa.

Chính phủ#

Một cơ quan công quốc gia hay địa phương — NHS England, DHSC, UKHSA, hay chính quyền địa phương — hoạt động dưới nghĩa vụ quản lý hồ sơ luật định, nghĩa vụ Tự do Thông tin và sự soi xét kiểm toán công, nên quản lý tri thức một phần là vấn đề pháp luật và trách nhiệm giải trình công. Quyết định về dịch vụ, tiền và chính sách phải được ghi lại, lưu giữ trong các khoảng thời gian xác định, và tìm thấy được nhiều năm sau cho các ủy ban chuyên trách, các cuộc rà soát của Văn phòng Kiểm toán Quốc gia và các cuộc điều tra công; lịch sử gần đây của các cuộc điều tra lớn cho thấy việc lưu hồ sơ kém tự nó trở thành một vụ bê bối ra sao. Chính phủ phải giữ vững ranh giới giữa hồ sơ luật định (được lưu giữ và hủy theo lịch) và tri thức làm việc (được quản lý theo độ mới), áp dụng Quy tắc Thực hành Quản lý Hồ sơ NHS có kỷ luật. Minh bạch là khẩu hiệu: giả định làm việc nên là tài liệu một ngày nào đó có thể được công chúng đọc.

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

• Người hùng và hệ số xe buýt bằng một. Tôn vinh cá nhân "cứ biết" hệ thống mà không bao giờ tài trợ công việc lan truyền tri thức đó. Nó cảm giác hiệu quả cho đến ngày họ không có mặt và một dịch vụ trọng yếu về an toàn không có ai vận hành được.
• Tài liệu viết một lần. Tài liệu được tạo trong lúc xây và không bao giờ chạm lại, trôi thành sự giả dối tự tin. Tài liệu cũ nguy hiểm hơn không có, vì người ta hành động theo chúng.
• Bãi rác wiki. Hàng nghìn trang, không cấu trúc, không người sở hữu, không ngày rà soát — tri thức về mặt kỹ thuật tồn tại nhưng không thể tìm hay tin. Nhầm khối lượng với giá trị.
• Tài liệu xa công việc. Tài liệu trong một công cụ riêng không ai mở khi lập trình, bảo đảm nó lệch khỏi thực tế. Tài liệu như mã là thuốc giải.
• Màn kịch rút bài học. Rà soát sau sự cố tạo ra tài liệu và danh sách hành động không bao giờ đóng, nên cùng sự cố tái diễn. Quy trình thành nghi thức, không phải cải tiến.
• Nhầm hồ sơ với ghi chú. Hoặc xóa thứ bạn bị pháp luật yêu cầu giữ, hoặc tích trữ mọi thứ mãi mãi và tạo ra khoản nợ bảo vệ dữ liệu và khả năng tìm thấy. Cả hai đều xuất phát từ việc không phân biệt hồ sơ luật định với tài liệu nhóm.
• Đổ lỗi trong phòng rà soát. Rà soát trừng phạt người gần thất bại nhất, dạy mọi người giấu nguyên nhân thực và phá hủy sự trung thực mà quy trình phụ thuộc.

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

Danh sách kiểm tra#

• Mọi hệ thống trọng yếu có sổ tay dịch vụ, sổ tay vận hành cập nhật và ADR cho các quyết định quan trọng của nó.
• Tài liệu là một phần của định nghĩa hoàn thành và được rà soát trong cùng pull request với thay đổi.
• Mỗi miền có một nguồn sự thật duy nhất có tên; các bản trùng lặp đã biết được xóa hoặc chuyển hướng.
• Hệ thống có hệ số xe buýt bằng một nằm trên sổ đăng ký rủi ro với người sở hữu và kế hoạch đào tạo chéo đang hoạt động.
• Sổ tay vận hành đã được kiểm thử bởi người không viết chúng, trong một buổi diễn tập hoặc một sự cố thật.
• Rà soát sau sự cố không đổ lỗi và tạo ra các hành động có chủ, có thời hạn được đóng.
• Cơ sở tri thức có cấu trúc rõ ràng, người sở hữu trang và ngày rà soát; trang cũ được tỉa.
• Có ít nhất một cộng đồng thực hành đang hoạt động cho một nghề xuyên các nhóm, với thời gian được bảo vệ.
• Hồ sơ luật định được phân biệt với tài liệu nhóm và được quản lý theo đúng lịch lưu giữ.
• Người mới được nhờ sửa khoảng trống tài liệu đầu tiên họ gặp như một đóng góp sớm.

Nguồn chính#

• NHS England / NHSX, Records Management Code of Practice 2021 — lịch lưu giữ luật định và nghĩa vụ vòng đời cho hồ sơ y tế và chăm sóc.
• GOV.UK Service Manual (Government Digital Service) — hướng dẫn viết cho và vận hành dịch vụ số, gồm tài liệu và vận hành một dịch vụ.
• NHS Digital Service Standard — kỳ vọng cho việc xây và duy trì dịch vụ số bền vững, có tài liệu tốt.
• Michael Nygard, "Documenting Architecture Decisions" (2011) — mô thức gốc cho bản ghi quyết định kiến trúc (ADR).
• Google, Site Reliability Engineering — rà soát sau sự cố không đổ lỗi (postmortem), sổ tay vận hành, và giảm rủi ro phụ thuộc người then chốt trong vận hành.
• Etienne Wenger, Communities of Practice: Learning, Meaning, and Identity (1998) — văn bản nền tảng về cộng đồng thực hành.
• Nonaka & Takeuchi, The Knowledge-Creating Company (1995) — mô hình SECI chuyển đổi tri thức từ ẩn sang tường minh.
• Cộng đồng Write the Docs — hướng dẫn của người hành nghề về tài liệu như mã và xem tài liệu như sản phẩm.

Tài liệu tham khảo#

1. Knowledge management — Wikipedia — https://en.wikipedia.org/wiki/Knowledge_management
2. Tacit knowledge — Wikipedia — https://en.wikipedia.org/wiki/Tacit_knowledge
3. Explicit knowledge — Wikipedia — https://en.wikipedia.org/wiki/Explicit_knowledge
4. SECI model of knowledge dimensions — Wikipedia — https://en.wikipedia.org/wiki/SECI_model_of_knowledge_dimensions
5. Bus factor — Wikipedia — https://en.wikipedia.org/wiki/Bus_factor
6. Runbook — Wikipedia — https://en.wikipedia.org/wiki/Runbook
7. Architectural decision — Wikipedia — https://en.wikipedia.org/wiki/Architectural_decision
8. Single source of truth — Wikipedia — https://en.wikipedia.org/wiki/Single_source_of_truth
9. Community of practice — Wikipedia — https://en.wikipedia.org/wiki/Community_of_practice
10. Records management — Wikipedia — https://en.wikipedia.org/wiki/Records_management
11. Information architecture — Wikipedia — https://en.wikipedia.org/wiki/Information_architecture
12. Postmortem documentation — Wikipedia — https://en.wikipedia.org/wiki/Postmortem_documentation
13. Onboarding — Wikipedia — https://en.wikipedia.org/wiki/Onboarding
14. Records Management Code of Practice 2021 — NHS England / NHSX — https://www.nhsx.nhs.uk/information-governance/guidance/records-management-code/
15. Service manual — Government Digital Service (GOV.UK) — https://www.gov.uk/service-manual
16. Documenting Architecture Decisions — Michael Nygard — https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions
17. Site Reliability Engineering — Google — https://sre.google/books/
18. Write the Docs — docs-as-code guidance — https://www.writethedocs.org/guide/docs-as-code/