Chủ đề 1.0 — Phương thức làm việc trong y tế và chăm sóc số

Tóm lại trong một câu: Phương thức làm việc là những thói quen chung, có chủ đích — cách bạn tổ chức nhóm, ra quyết định, quản lý rủi ro và tạo ra giá trị — giúp một tổ chức y tế và chăm sóc biến ý định thành những kết quả an toàn, công bằng và dựa trên bằng chứng cho bệnh nhân và công dân.

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

Tổ chức nào cũng có phương thức làm việc, dù do tự chọn hay do thừa hưởng. Trong y tế và chăm sóc số, những phương thức bạn thừa hưởng thường không phù hợp với công việc: chúng được xây dựng cho các dự án kiểu xây dựng với phạm vi cố định, chứ không phải cho các dịch vụ thích ứng chạm đến an toàn lâm sàng, nghĩa vụ theo luật định và tiền công. Làm đúng chúng không phải là một sự chỉn chu ở hậu trường; đó là ranh giới giữa một hồ sơ chăm sóc dùng chung mà các bác sĩ tin tưởng và một hồ sơ bị bỏ không.

Y tế và chăm sóc có những nét riêng định hình mọi thực hành trong cuốn sách này. An toàn là điều không thể thương lượng — một lỗi trong dịch vụ số có thể gây hại cho bệnh nhân, nên quản lý rủi ro lâm sàng (xem Chủ đề 1.6 — An toàn lâm sàng và quản lý rủi ro) được lồng vào suốt quá trình triển khai chứ không phải gắn thêm vào sau. Công bằng quan trọng vì một dịch vụ chỉ hoạt động tốt với những người thành thạo công nghệ số sẽ làm gia tăng bất bình đẳng về sức khỏe; các nhóm dân số Core20PLUS5 và những người hạn chế về khả năng tiếp cận số phải được tính đến khi thiết kế, chứ không bị thiết kế loại bỏ. Nghĩa vụ theo luật định — cam kết của NHS về chăm sóc toàn diện, luật bảo vệ dữ liệu, nghĩa vụ bảo mật — giới hạn những gì bạn được làm với dữ liệu và cách bạn phải tham vấn. Tiền công đòi hỏi kiểm soát chi tiêu tương xứng và giá trị có thể chứng minh. Và hầu như không có gì được thực hiện bởi một đơn vị duy nhất: quan hệ đối tác giữa các hệ thống chăm sóc tích hợp (ICS), chính quyền địa phương, các nhà cung cấp dịch vụ chăm sóc xã hội và các nhà cung cấp là điều kiện vận hành mặc định.

Bốn áp lực này — an toàn, công bằng, nghĩa vụ, tiền bạc — là lý do bạn không thể đơn giản sao chép cẩm nang của ngành công nghệ tiêu dùng. Bạn cần những phương thức làm việc vừa linh hoạt vừa có trách nhiệm giải trình, vừa nhanh vừa an toàn, vừa lấy người dùng làm trung tâm vừa công bằng với toàn dân số.

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

Phương thức làm việc vận hành ở ba cấp độ. Ở cấp nhóm, đó là các thực hành hằng ngày: họp đứng, nghiên cứu người dùng, triển khai lặp, làm việc theo cặp. Ở cấp tổ chức, đó là mô hình vận hành — cách chiến lược trở thành các dòng giá trị, năng lực, nguồn tài trợ và quyền ra quyết định (xem Chủ đề 1.1 — Mô hình vận hành). Ở cấp hệ thống, đó là cách các tổ chức độc lập phối hợp: các tiêu chuẩn chung, khả năng tương tác và quản trị chung trong một ICS. Cuốn sách này chủ ý di chuyển qua cả ba cấp.

Thiết kế lấy người dùng làm trung tâm nghĩa là bắt đầu từ nhu cầu của những người sử dụng dịch vụ — bệnh nhân, người chăm sóc, bác sĩ lâm sàng, nhân viên hành chính — thay vì từ một giải pháp đã được giả định. Dịch vụ Số của Chính phủ Vương quốc Anh (GDS) và NHS đã hệ thống hóa điều này trong các tiêu chuẩn dịch vụ: hiểu người dùng và nhu cầu của họ trước khi xây dựng, và liên tục thử nghiệm với người dùng thực trong suốt quá trình.

Triển khai lặp, linh hoạt (agile) nghĩa là đưa một dịch vụ đang hoạt động đến tay người dùng thực từ sớm, học hỏi và điều chỉnh — thay vì đặc tả mọi thứ ngay từ đầu. Sổ tay dịch vụ số của NHS nêu rõ rằng các phương thức làm việc linh hoạt, lấy người dùng làm trung tâm làm giảm rủi ro xây nhầm thứ. Ở đây, agile vừa là một chiến lược quản lý rủi ro vừa là một phương pháp triển khai.

Nhóm đa ngành (MDT) quy tụ, trong một nhóm được trao quyền, sự kết hợp các kỹ năng mà một dịch vụ cần: quản lý sản phẩm và triển khai, nghiên cứu và thiết kế người dùng, kỹ thuật, chuyên môn lâm sàng và quản trị thông tin, cùng hiểu biết vận hành. Tiêu chuẩn dịch vụ của NHS yêu cầu các nhóm có kỹ năng và góc nhìn đa ngành — bao gồm khả năng tiếp cận ý kiến chuyên gia về lâm sàng, pháp lý hoặc chính sách. MDT là nguyên tử của triển khai số; hầu hết các thất bại đều bắt nguồn từ việc thiếu một ngành chuyên môn trên bàn làm việc.

Sản phẩm thay vì dự án. Một dự án có điểm bắt đầu, điểm kết thúc và bàn giao; một sản phẩm được tài trợ và quản lý trong suốt vòng đời của nó. Sự chuyển dịch từ tư duy dự án sang tư duy sản phẩm (xem Chủ đề 1.1 và Chủ đề 5.0 — Công việc dẫn dắt bởi sản phẩm) thay đổi nguồn tài trợ, nhóm và trách nhiệm giải trình, và nó phù hợp với các dịch vụ y tế — vốn tồn tại lâu dài và liên tục phát triển — hơn nhiều so với các dự án một lần.

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

1. Bắt đầu từ nhu cầu người dùng, được chứng minh bằng nghiên cứu. Trước khi cam kết xây dựng, hãy hiểu người dùng là ai, họ đang cố làm gì và dịch vụ hiện tại làm họ thất vọng ở đâu. Tài trợ một giai đoạn khám phá (xem Chủ đề 3.4 — Giai đoạn khám phá) và xem câu "chúng tôi đã giả định" là dấu hiệu cảnh báo. Nhu cầu của người dùng, chứ không phải sở thích nội bộ, là điểm neo cho mọi quyết định sau này.

2. Xây dựng các nhóm đa ngành, được trao quyền và ổn định. Tập hợp đầy đủ các kỹ năng — bao gồm an toàn lâm sàng và quản trị thông tin — và trao cho nhóm thẩm quyền quyết định trong những giới hạn rõ ràng. Giữ các nhóm gắn bó quanh một dịch vụ thay vì giải tán họ ở mỗi ranh giới dự án; các nhóm ổn định tích lũy kiến thức chuyên ngành và an toàn mà các dịch vụ y tế đòi hỏi.

3. Làm việc công khai và lặp theo các bước nhỏ. Phát hành những lát cắt mỏng, đo lường và điều chỉnh. Các bản phát hành nhỏ, thường xuyên an toàn hơn các lần ra mắt "một vụ nổ lớn" vì vấn đề bộc lộ khi còn nhỏ, và chúng giúp việc rà soát an toàn lâm sàng và quản trị thông tin theo kịp thay đổi thay vì trở thành một cổng chặn ở cuối.

4. Đặt an toàn và công bằng lên hàng đầu ngay từ ngày đầu tiên. Thực hiện quản lý rủi ro lâm sàng (DCB0129/DCB0160) và phân tích bình đẳng/bất bình đẳng sức khỏe song song với triển khai, chứ không phải các bước phê duyệt ở giai đoạn cuối. Hãy sớm hỏi ai có thể bị loại trừ hoặc bị tổn hại, và thiết kế cho những trường hợp khó nhất — kênh hỗ trợ số có người hướng dẫn, khả năng tiếp cận (WCAG) và các phương án dự phòng ngoại tuyến.

5. Quyết định bằng bằng chứng, và ghi lại quyết định. Phân biệt bằng chứng lâm sàng (nó có hiệu quả và an toàn không?) với bằng chứng triển khai (chúng ta có xây dựng tốt và được sử dụng không?), và duy trì một nhật ký quyết định gọn nhẹ để lập luận không bị mất khi nhân sự thay đổi (xem Chủ đề 1.3 — Quyết định dựa trên bằng chứng). Bằng chứng thắng ý kiến của người được trả lương cao nhất.

6. Thiết kế để tương tác và tái sử dụng. Dữ liệu y tế và chăm sóc phải luân chuyển an toàn giữa các tổ chức; hãy xây dựng theo các chuẩn mở (HL7 FHIR, SNOMED CT) và tái sử dụng các nền tảng thay vì phát minh lại (xem "nền tảng khả thi mỏng nhất" ở Chủ đề 1.1 và Chủ đề 4.3 — Khả năng tương tác và chuẩn dữ liệu). Một dịch vụ không thể chia sẻ dữ liệu là một ốc đảo đang chờ trở thành rủi ro.

7. Quản trị tương xứng. Điều chỉnh mức độ đảm bảo theo mức độ rủi ro. Các thay đổi lâm sàng rủi ro cao đáng được xem xét kỹ; các thay đổi nội dung rủi ro thấp không nên phải chờ nhiều tuần cho một hội đồng. Quản trị tương xứng giúp bạn vừa an toàn vừa nhanh.

8. Làm việc công khai. Chia sẻ kế hoạch, quyết định, lộ trình và — khi an toàn — cả mã nguồn, để các đối tác, bác sĩ lâm sàng và công chúng thấy các lựa chọn được đưa ra như thế nào và vì sao. Sự công khai xây dựng niềm tin, giảm trùng lặp trong một hệ thống phân mảnh, và mời gọi phản biện trước khi sai lầm kết tinh thành các dịch vụ đang vận hành. Trong y tế và chăm sóc, minh bạch về việc một dịch vụ làm gì với dữ liệu và vì sao, tự nó là một thực hành về niềm tin và an toàn.

9. Thiết kế cho dài hạn và cho việc bàn giao. Các dịch vụ số trong y tế tồn tại lâu hơn các nhóm và hợp đồng xây dựng chúng, vì vậy hãy ghi lại các quyết định, tránh kiến thức "anh hùng" không được ghi chép, và thiết kế cho những người sẽ vận hành và thay đổi dịch vụ trong nhiều năm (xem Chủ đề 10.3 — Quản lý tri thức và tài liệu). Hãy coi tính bền vững — của nhóm, công nghệ và mô hình tài trợ — là một ràng buộc hàng đầu, không phải điều nghĩ sau.

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

1. Phương thức làm việc hiện tại của chúng ta ở đâu là thừa hưởng chứ không phải tự chọn, và thói quen thừa hưởng nào đang khiến chúng ta tốn kém nhất về an toàn, công bằng hoặc chi tiêu lãng phí? Câu hỏi này buộc phải kiểm toán trung thực những thực hành mà không ai quyết định nhưng ai cũng theo — tài trợ chương trình với phạm vi cố định, giải tán rồi dựng lại nhóm dự án, quản trị chỉ được tham vấn vào lúc đưa vào vận hành. Điều này quan trọng vì các thói quen thừa hưởng thường vô hình cho đến khi được gọi tên, và trong y tế và chăm sóc chúng mang chi phí thực: một hồ sơ dùng chung mà bác sĩ không tin tưởng, một dịch vụ loại trừ các nhóm dân số Core20PLUS5, hoặc việc xây lại cùng một hạ tầng đăng nhập bằng tiền công. Căng thẳng cần tranh luận là các cách làm thừa hưởng thường có vẻ an toàn chính vì chúng quen thuộc và có thể kiểm toán, nên việc loại bỏ chúng trông như gánh thêm rủi ro thay vì gỡ bỏ rủi ro. Hãy dựa cuộc thảo luận trên các hiện vật cụ thể — xem ba hồ sơ kinh doanh gần nhất, mức luân chuyển nhân sự giữa các dự án, và thời điểm an toàn lâm sàng được tham gia lần đầu — thay vì trao đổi ý kiến. Một câu trả lời tốt nêu một hoặc hai thói quen cụ thể kèm bằng chứng về chi phí của chúng, phân biệt những thói quen đáng giữ với những thói quen đang gây hại cho kết quả, và cam kết một thay đổi mà một lãnh đạo cấp cao sẽ chịu trách nhiệm.

2. Các nhóm của chúng ta có thực sự có đầy đủ sự kết hợp kỹ năng đa ngành — bao gồm an toàn lâm sàng và quản trị thông tin — nằm ngay trong nhóm, hay những ngành đó vẫn bị gắn thêm như các cổng chặn ở giai đoạn cuối? Chủ đề lập luận rằng MDT là nguyên tử của triển khai số và hầu hết thất bại bắt nguồn từ việc thiếu một ngành trên bàn làm việc, nên câu hỏi này kiểm tra xem nguyên tắc đó là thực tế hay chỉ là khát vọng trong tổ chức của bạn. Điều này quan trọng vì một cán bộ an toàn lâm sàng hoặc Người bảo vệ Caldicott chỉ được tham gia vào lúc vận hành sẽ buộc phải làm lại hoặc đi đường tắt thiếu an toàn, trong khi người được lồng vào từ tuần đầu tiên sẽ duy trì một nhật ký mối nguy sống, định nhịp cho việc triển khai. Sự đánh đổi đáng nêu ra là chi phí và sự khan hiếm: thời gian của chuyên gia lâm sàng, pháp lý và quản trị thông tin thực sự có hạn, nên "lồng mọi người vào mọi nhóm" va chạm với các ràng buộc nguồn lực thực tế, và nhóm phải quyết định chỗ nào chấp nhận vai trò bán thời gian hoặc dùng chung và chỗ nào thì không. Hãy xem xét một dịch vụ hiện tại và lập bản đồ ai thực sự nằm trong nhóm thường trực so với ai chỉ được tham vấn như một khâu phê duyệt bên ngoài, và kiểm tra xem nhóm có thẩm quyền quyết định trong các giới hạn hay phải liên tục báo cáo lên cấp trên. Một câu trả lời trung thực và tốt nêu cụ thể những ngành nào đang thiếu hoặc đi mượn, thẳng thắn thừa nhận căng thẳng về nguồn lực, và đề xuất một mô hình cụ thể — toàn thời gian, bán thời gian hoặc trực khi cần — để lấp khoảng trống mà không giả vờ rằng sự khan hiếm không tồn tại.

3. Chúng ta đã khi nào xem một dịch vụ số như một dự án có bàn giao thay vì một sản phẩm được quản lý suốt vòng đời, và điều đó khiến chúng ta mất bao nhiêu kiến thức chuyên ngành và an toàn? Sản phẩm thay vì dự án là một trong những chuyển dịch chịu lực của chủ đề, và câu hỏi này khiến nhóm đối diện với chỗ họ vẫn tài trợ và bố trí nhân sự cho sự kết thúc thay vì sự liên tục. Điều này quan trọng vì các dịch vụ y tế tồn tại lâu dài và liên tục phát triển; một nhóm bị giải tán ở ranh giới dự án mang theo chính kiến thức lâm sàng và vận hành tích lũy giữ cho dịch vụ an toàn, và "luyện ngục thí điểm" là triệu chứng lặp lại. Căng thẳng thực sự mang tính tài chính và cấu trúc: tài trợ theo sản phẩm đòi hỏi ngân sách thường trực và thách thức mô hình đấu thầu hằng năm, giới hạn thời gian mà bộ phận tài chính và quản trị được xây dựng quanh, nên đây là cuộc trò chuyện về tiền bạc và trách nhiệm giải trình không kém gì về triển khai. Hãy xem xét một dịch vụ cụ thể đã trải qua bàn giao — lần theo điều gì đã xảy ra với nhật ký mối nguy, nghiên cứu người dùng và nhóm của nó — và cân nhắc điều đó với kỷ luật mà tài trợ theo sản phẩm đòi hỏi. Một câu trả lời tốt xác định một trường hợp cụ thể, định lượng hoặc ít nhất mô tả kiến thức đã mất, và thẳng thắn về những rào cản tổ chức nào (chu kỳ tài trợ, quy tắc nguồn lực, cấu trúc quản trị) phải thay đổi để các nhóm sản phẩm bền vững trở thành chuẩn mực.

4. Ai có khả năng cao nhất bị loại trừ hoặc bị tổn hại bởi các dịch vụ chúng ta xây dựng, và chúng ta có thể chỉ ra nơi mình đã thiết kế cho họ trước chứ không phải sau cùng không? Chủ đề khẳng định rằng công bằng là điều không thể thương lượng và một dịch vụ chỉ hiệu quả với những người thành thạo số sẽ làm gia tăng bất bình đẳng sức khỏe, nên câu hỏi này kiểm tra xem "thiết kế cho các trường hợp khó nhất" là một thực hành sống hay chỉ là khẩu hiệu. Điều này quan trọng vì sự loại trừ trong y tế và chăm sóc không phải là bất tiện mà là tổn hại về an toàn và tiếp cận: các nhóm dân số Core20PLUS5, những người hạn chế về tiếp cận số, hiểu biết sức khỏe thấp hoặc không có điện thoại thông minh chính là những người có nhu cầu lớn nhất, và một dịch vụ thiết kế loại họ ra sẽ dồn tổn hại vào nơi ít gánh nổi nhất. Căng thẳng đáng nêu ra là thiết kế cho các nhóm ngoại vi tốn thời gian và tiền bạc ngay từ đầu — kênh hỗ trợ số có người hướng dẫn, khả năng tiếp cận theo WCAG, các phương án ngoại tuyến và phi số, dịch thuật — và những chi phí này dễ bị hoãn khi hạn chót đến gần và đa số thành thạo đã dùng được sản phẩm. Hãy xem một dịch vụ thực và hỏi ai nằm trong mẫu nghiên cứu người dùng của nó, liệu một phân tích bình đẳng và bất bình đẳng sức khỏe có thực sự định hình một quyết định thiết kế hay không, và điều gì xảy ra với người không thể hoặc không muốn lên mạng. Một câu trả lời trung thực nêu các nhóm cụ thể có nguy cơ đối với dịch vụ này, cho thấy ít nhất một lựa chọn thiết kế cụ thể được đưa ra vì họ, và thẳng thắn về chỗ nhóm đã đánh đổi sự hòa nhập dưới áp lực và sẽ bảo vệ sự đánh đổi đó thế nào vào lần sau.

5. Chúng ta đang phát minh lại hạ tầng đã có ở đâu, và việc xây dựng theo chuẩn mở cùng tái sử dụng các nền tảng dùng chung sẽ thực sự thay đổi những gì chúng ta phát hành ở đâu? Thiết kế để tương tác và tái sử dụng là một trong những thực hành tốt nhất của chủ đề, và câu hỏi này khiến nhóm đối diện với sức hút của việc xây riêng thay vì tái sử dụng — chức năng đăng nhập, thông báo, tích hợp hồ sơ mà hàng chục nhóm khác cũng đã xây. Điều này quan trọng vì trong một hệ thống phân mảnh, mỗi thành phần được phát minh lại là tiền công chi hai lần và là một ốc đảo mới không thể trao đổi dữ liệu an toàn; ngược lại, xây dựng theo HL7 FHIR và SNOMED CT và tái sử dụng nền tảng khả thi mỏng nhất là điều cho phép một dịch vụ vượt qua mua sắm và chia sẻ dữ liệu xuyên ICS. Sự đánh đổi thực sự là tái sử dụng nghĩa là phụ thuộc: một nền tảng dùng chung có thể chậm hơn, kém tùy biến hơn, hoặc chịu sự chi phối của lộ trình của người khác, nên nhóm phải cân nhắc lực cản của thành phần dùng chung với chi phí và rủi ro dài hạn của một ốc đảo tự xây. Hãy xem xét một bản dựng hiện tại và liệt kê điều gì thực sự mới so với điều gì trùng lặp với một nền tảng, chuẩn hoặc thành phần mở sẵn có, và kiểm tra xem "chúng ta không thể tái sử dụng cái đó" là một ràng buộc có bằng chứng hay một giả định chưa được kiểm chứng. Một câu trả lời tốt phân biệt các phần đáng xây với các phần đáng tái sử dụng, trung thực về độ trưởng thành và quản trị của các nền tảng hiện có, và cam kết dùng chuẩn mở cho mọi thứ phải trao đổi dữ liệu.

6. Chúng ta điều chỉnh mức độ quản trị theo mức độ rủi ro như thế nào, và hiện đảm bảo đang quá nặng đối với thay đổi rủi ro thấp hay quá nhẹ đối với thay đổi rủi ro cao ở đâu? Quản trị tương xứng là một ý tưởng chịu lực trong chủ đề này — các thay đổi lâm sàng rủi ro cao đáng được xem xét kỹ trong khi các thay đổi nội dung rủi ro thấp không nên chờ nhiều tuần cho một hội đồng — và câu hỏi này kiểm tra xem tổ chức có hiệu chỉnh đảm bảo theo rủi ro hay áp dụng một quy trình cứng nhắc cho mọi thứ. Điều này quan trọng vì quản trị đặt sai gây hại theo cả hai hướng: một cổng chặn nặng nề cho tất cả khiến các nhóm gom thay đổi lại và làm chậm chính sự lặp lại giữ cho dịch vụ an toàn, trong khi sự nhẹ tay đồng đều để lọt một thay đổi lâm sàng thực sự rủi ro cao mà không qua sự xem xét an toàn lâm sàng và quản trị thông tin cần thiết. Căng thẳng là sự tương xứng đòi hỏi phán đoán, và phán đoán gây khó chịu cho các hội đồng và kiểm toán viên, những người thấy một danh sách kiểm tra bắt buộc duy nhất dễ bảo vệ hơn một lộ trình phân tầng theo rủi ro. Hãy xem mười hai thay đổi gần nhất của bạn đã được đảm bảo như thế nào, sắp xếp chúng theo rủi ro lâm sàng và dữ liệu thực tế, và xem công sức bỏ ra bám theo rủi ro hay bám theo lịch. Một câu trả lời trung thực xác định các ví dụ cụ thể về cả quản trị quá mức lẫn quản trị thiếu, đề xuất tiêu chí rõ ràng để phân tầng thay đổi theo rủi ro, và nêu ai nắm thẩm quyền quyết định tầng và chịu trách nhiệm về nó.

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 muốn trao cho các bác sĩ lâm sàng tại ba bệnh viện cấp cứu, các dịch vụ cộng đồng và chăm sóc xã hội của chính quyền địa phương một hồ sơ chăm sóc dùng chung. Cách cũ sẽ ủy thác một chương trình có phạm vi cố định, đặc tả mọi màn hình ngay từ đầu và tích hợp muộn.

Thay vào đó, ICS thành lập một nhóm đa ngành: một quản lý sản phẩm, một quản lý triển khai, một nhà nghiên cứu người dùng, một nhà thiết kế tương tác, hai kỹ sư, một cán bộ an toàn lâm sàng và một trưởng bộ phận quản trị thông tin, với khả năng tiếp cận một Người bảo vệ Caldicott và một người hành nghề chăm sóc xã hội. Họ thực hiện một giai đoạn khám phá kéo dài tám tuần, quan sát cách một điều dưỡng khu vực, một bác sĩ tư vấn khoa cấp cứu và một nhân viên xã hội thực sự cố tìm thông tin hiện nay. Họ phát hiện ra nỗi đau thực sự không phải là "không có dữ liệu" mà là "dữ liệu mà họ không thể tin tưởng về độ cập nhật".

Nhóm phát hành một bản alpha hẹp: truy cập chỉ đọc vào dị ứng, thuốc và tình trạng kế hoạch chăm sóc hiện tại cho một lộ trình lâm sàng, với dấu "cập nhật lần cuối" hiển thị rõ. An toàn lâm sàng chạy song song; một nhật ký mối nguy được duy trì từ tuần đầu tiên. Họ đo xem các bác sĩ có ngừng gọi điện cho các nhóm khác để xác nhận thông tin hay không. Chỉ khi lát cắt mỏng đó chứng tỏ có giá trị và an toàn, họ mới mở rộng hồ sơ — được tài trợ như một sản phẩm liên tục, không phải một dự án đã khép lại.

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

Bốn áp lực giống nhau — an toàn, công bằng, nghĩa vụ, tiền bạc — tác động lên mọi tổ chức, nhưng các phương thức làm việc đáp ứng chúng thay đổi theo quy mô, nguồn tài trợ và trách nhiệm giải trình.

Công ty khởi nghiệp#

Một công ty y tế số nhỏ sống hay chết nhờ sự tập trung, nên phương thức làm việc của nó tinh gọn do bắt buộc: một nhóm đa ngành, ra quyết định phẳng và tiếp xúc hằng ngày với người dùng. Ràng buộc là thời gian còn tiền (runway), không phải quy tắc về quân số, nên giai đoạn khám phá được đo bằng tuần và bằng chứng được thu thập rẻ — một vài cuộc phỏng vấn lâm sàng, một nguyên mẫu có thể nhấp, một nhật ký mối nguy trung thực do một cán bộ an toàn lâm sàng bán thời gian duy trì. Nguy cơ là bỏ qua sự nghiêm ngặt về an toàn và quản trị thông tin để đạt cột mốc của nhà đầu tư; kỷ luật vượt qua được sự soi xét là xem DCB0129 và đánh giá tác động bảo vệ dữ liệu (DPIA) là tiêu chí đầu vào của một thí điểm, chứ không phải giấy tờ hoãn lại cho đến khi một bệnh viện yêu cầu. Khả năng tương tác ngay từ ngày đầu (FHIR, SNOMED CT) cũng là một tài sản thương mại, vì một công ty khởi nghiệp không thể trao đổi dữ liệu sẽ không bao giờ vượt qua được mua sắm của NHS.

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ế quy mô khiêm tốn đã qua giai đoạn chưa có doanh thu — chịu cùng những áp lực về an toàn, công bằng, nghĩa vụ và tiền bạc như một bệnh viện lớn nhưng chỉ có một phần nhỏ năng lực để đáp ứng. Phương thức làm việc ở đây phải tương xứng một cách triệt để: hiếm khi có đội số hoặc quản trị thông tin chuyên trách, nên "nhóm đa ngành" thường là một nhóm nhỏ người kiêm nhiều vai cùng một nguồn lực an toàn lâm sàng và bảo vệ dữ liệu dùng chung hoặc thuê ngoài. Cái bẫy là cho rằng các nghĩa vụ theo luật định thu nhỏ theo tổ chức — chúng không thu nhỏ, nên an toàn lâm sàng DCB0129/DCB0160, đánh giá tác động bảo vệ dữ liệu và khả năng tiếp cận vẫn áp dụng đầy đủ ngay cả khi một người quản lý phòng khám duy nhất chịu trách nhiệm về tất cả. Kỷ luật thực tế là dựa mạnh vào tái sử dụng thay vì tự xây: áp dụng các hệ thống thương mại đã được công nhận, yêu cầu nhà cung cấp đáp ứng DTAC và các chuẩn mở (FHIR, SNOMED CT), và dùng các nền tảng quốc gia và của ICS để an toàn, khả năng tương tác và quản trị thông tin được thừa hưởng thay vì phát minh lại với nguồn lực eo hẹp.

Doanh nghiệp lớn#

Một bệnh viện NHS hoặc ICS có vấn đề ngược lại: quy trình dồi dào và quyền sở hữu phân mảnh. Phương thức làm việc ở đây liên quan đến việc bỏ thói quen cũ — loại bỏ các thói quen chương trình phạm vi cố định, ngừng việc giải tán rồi dựng lại các nhóm dự án — nhiều không kém việc áp dụng các thực hành mới. Trách nhiệm giải trình mang tính chính thức và cá nhân (một chủ sở hữu chịu trách nhiệm cấp cao, một Người bảo vệ Caldicott, phê duyệt an toàn lâm sàng cấp hội đồng quản trị), nên chiến thắng là lồng các vai trò đó vào bên trong nhóm triển khai thay vì gắn thêm chúng như các cổng chặn. Một nhà cung cấp công nghệ y tế hoặc dược phẩm lớn đối mặt với bức tranh phản chiếu: độ trưởng thành kỹ thuật mạnh nhưng xa cách thực tế lâm sàng tuyến đầu, điều mà các nhóm đa ngành có thời gian thực của bác sĩ tồn tại để thu hẹp.

Chính phủ#

Một cơ quan công quyền quốc gia hoặc địa phương — NHS England, DHSC, UKHSA, một chính quyền địa phương — đặt ra các tiêu chuẩn mà mọi người khác làm theo, nên phương thức làm việc của nó lan tỏa ra bên ngoài. Trách nhiệm giải trình của nó là trước Nghị viện và công chúng, điều này nâng cao yêu cầu về minh bạch, kiểm soát chi tiêu và công bằng: một tiêu chuẩn dịch vụ, một lộ trình đảm bảo được công bố và các nghĩa vụ Core20PLUS5 là công cụ của trách nhiệm giải trình đó, không phải phần bổ sung tùy chọn. Rủi ro ở quy mô này là thiết kế tập trung cho một công dân trung bình không tồn tại và áp đặt một giải pháp trước khi hiểu nhu cầu địa phương. Cách khắc phục vẫn là kỷ luật lặp, lấy người dùng làm trung tâm như mọi nơi khác, được áp dụng với thiên hướng thiết lập các chuẩn mở và nền tảng tái sử dụng mà các tổ chức liên bang có thể xây dựng trên đó — quản trị hệ thống, chứ không chỉ cung cấp một dịch vụ.

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

• Triển khai giải pháp trước. Cam kết với một sản phẩm cụ thể trước khi hiểu nhu cầu. Giải pháp: tài trợ khám phá và đặt nhu cầu người dùng làm tiêu chí đầu vào cho xây dựng.
• Quản trị như một cổng chặn muộn. An toàn lâm sàng và quản trị thông tin chỉ được tham vấn lúc vận hành, buộc phải làm lại hoặc đi đường tắt thiếu an toàn. Giải pháp: lồng cả hai vào nhóm từ ngày đầu tiên.
• Xáo trộn dự án. Dựng nhóm lên rồi giải tán, đánh mất kiến thức chuyên ngành và an toàn khó khăn mới có. Giải pháp: tài trợ theo sản phẩm và các nhóm bền vững.
• Luyện ngục thí điểm. Các thí điểm vô tận không bao giờ mở rộng vì việc chấp nhận, đào tạo và thay đổi kinh doanh chưa bao giờ được cấp nguồn lực (xem Chủ đề 8.1 — Quản lý thay đổi). Giải pháp: lập kế hoạch lộ trình mở rộng trước khi thí điểm.
• Công bằng như điều nghĩ sau. Thiết kế cho đa số thành thạo và loại trừ những người cần chăm sóc nhất. Giải pháp: thiết kế cho các trường hợp khó nhất trước.

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

Danh sách kiểm tra#

• Mọi dịch vụ đều có một nhóm đa ngành ổn định, được chỉ định, với kỹ năng an toàn lâm sàng và quản trị thông tin.
• Không bản dựng nào bắt đầu mà thiếu nhu cầu người dùng đã được chứng minh từ giai đoạn khám phá.
• Quản lý rủi ro lâm sàng (DCB0129/DCB0160) chạy từ ngày đầu tiên, với một nhật ký mối nguy sống.
• Đã thực hiện một phân tích công bằng/bất bình đẳng sức khỏe, và có các kênh hỗ trợ số có người hướng dẫn.
• Việc triển khai tiến hành theo các lát cắt nhỏ, thường xuyên, đo lường được.
• Các quyết định được ghi lại, phân biệt bằng chứng lâm sàng với bằng chứng triển khai.
• Các dịch vụ được xây dựng theo chuẩn tương tác mở và tái sử dụng các nền tảng dùng chung.
• Mức độ quản trị được điều chỉnh theo rủi ro, và nhóm biết điều đó.
• Có một lộ trình được tài trợ từ thí điểm đến mở rộng, bao gồm đào tạo và thay đổi.

Nguồn chính#

• Sổ tay dịch vụ số của NHS — Tiêu chuẩn dịch vụ NHS và các điểm của nó, bao gồm "Sử dụng các phương thức làm việc linh hoạt (agile)" và "Tạo một nhóm có kỹ năng và góc nhìn đa ngành" (service-manual.nhs.uk).
• Sổ tay Dịch vụ GOV.UK và Tiêu chuẩn Dịch vụ Chính phủ — Dịch vụ Số của Chính phủ (gov.uk/service-manual).
• NHS England / NHSX — Tiêu chí Đánh giá Công nghệ Số (DTAC).
• Các tiêu chuẩn an toàn lâm sàng DCB0129 và DCB0160 (NHS England / NHS Digital trước đây).
• NICE — Khung Tiêu chuẩn Bằng chứng cho công nghệ y tế số (nice.org.uk).
• NHS England — cách tiếp cận Core20PLUS5 nhằm giảm bất bình đẳng sức khỏe.

Tài liệu tham khảo#

1. User-centered design — Wikipedia — https://en.wikipedia.org/wiki/User-centered_design
2. Government Digital Service — Wikipedia — https://en.wikipedia.org/wiki/Government_Digital_Service
3. Agile software development — Wikipedia — https://en.wikipedia.org/wiki/Agile_software_development
4. Iterative and incremental development — Wikipedia — https://en.wikipedia.org/wiki/Iterative_and_incremental_development
5. Interdisciplinarity — Wikipedia — https://en.wikipedia.org/wiki/Interdisciplinarity
6. Product management — Wikipedia — https://en.wikipedia.org/wiki/Product_management
7. Health equity — Wikipedia — https://en.wikipedia.org/wiki/Health_equity
8. Web Content Accessibility Guidelines — Wikipedia — https://en.wikipedia.org/wiki/Web_Content_Accessibility_Guidelines
9. Fast Healthcare Interoperability Resources (HL7 FHIR) — Wikipedia — https://en.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources
10. SNOMED CT — Wikipedia — https://en.wikipedia.org/wiki/SNOMED_CT
11. NHS service standard — NHS digital service manual, NHS England — https://service-manual.nhs.uk/standards-and-technology/service-standard
12. Government Service Standard — Government Digital Service, GOV.UK — https://www.gov.uk/service-manual/service-standard
13. Digital Technology Assessment Criteria (DTAC) — NHS England — https://www.nhs.uk/digital-technology-assessment-criteria-dtac/
14. Clinical Risk Management: DCB0129 and DCB0160 — NHS England — https://digital.nhs.uk/services/clinical-safety
15. Evidence Standards Framework for digital health technologies — NICE — https://www.nice.org.uk/about/what-we-do/digital-health
16. Core20PLUS5 — NHS England — https://www.england.nhs.uk/about/equality/equality-hub/national-healthcare-inequalities-improvement-programme/core20plus5/