HCM TRƯỜNG ĐẠI HỌC BÁCH KHOA --- NGUYỄN ĐOÀN HỮU PHÚC ỨNG DỤNG CÔNG NGHỆ CHUỖI KHỐI TRONG QUẢN LÝ DỮ LIỆU HIẾN NOÃN TẠI VIỆT NAM Chuyên ngành: Hệ thống thông tin Quản lý Mã số: 8340405
TỔNG QUAN
Giới thiệu về hiếm muộn và hoạt động hiến noãn
2.1.1.1 Chức năng và nhiệm vụ
Trung tâm hiếm muộn, hay ở một vài bệnh viện còn được gọi là Đơn vị hỗ trợ sinh sản, có chức năng và nhiệm vụ được mô tả theo Hình 2.1 từ kết quả khảo sát của tác giả:
- Khám, chẩn đoán, tư vấn, điều trị các trường hợp vô sinh, hiếm muộn, thực hiện tất cả các kỹ thuật hỗ trợ sinh sản hiện thế giới đang áp dụng
- Khám, chẩn đoán, tư vấn, điều trị và thực hiện các kỹ thuật hỗ trợ sinh sản cho các cặp vợ chồng mang bệnh lý di truyền hoặc có bất thường về gen, nhiễm sắc thể… giúp họ sinh con khỏe mạnh theo phương pháp khoa học
- Nghiên cứu khoa học, tham gia đào tạo, bồi dưỡng chuyển giao công nghệ về lĩnh vực hỗ trợ sinh sản và hợp tác quốc tế trong lĩnh vực chuyên môn Đội ngũ cán bộ, y bác sĩ
- Trung tâm Hỗ trợ sinh sản có đội ngũ cán bộ, y bác sĩ, chuyên viên sinh học, kỹ thuật viên giỏi chuyên môn, nhiều năm kinh nghiệm, thuần thục các thao tác kỹ thuật, tỉ mỉ và chính xác, tận tâm với người bệnh
Hình 2.1 Quy trình mô tả các bước quản lý khám và điều trị hiếm muộn
Các kỹ thuật hỗ trợ sinh sản của một Trung tâm hiếm muộn đang thực hiện:
- Bơm tinh trùng vào buồng tử cung (IUI)
- Thụ tinh trong ống nghiệm (IVF)
- Tiêm tinh trùng vào bào tương trứng (ICSI)
- Thu nhận tinh trùng từ mào tinh (PESA, TESE)
- Thu nhận tinh trùng từ vi phẫu tinh hoàn (MICRO TESE)
- Đông phôi theo phương pháp thủy tinh hóa, hỗ trợ phôi thoát màng, chuyển phôi đông lạnh…
2.1.1.2 Các ứng dụng hỗ trợ hoạt động thăm khám và điều trị hiếm muộn
Tại một trung tâm hiếm muộn có rất nhiều hoạt động diễn ra theo tiến trình điều trị của bệnh nhân Toàn bộ quá trình thăm khám, đều được hỗ trợ bởi hệ thống thông tin Qua khảo sát tại Trung tâm hỗ trợ sinh sản IVFMD, có thể liệt kê một số ứng dụng tương ứng với các bước thực hiện tại Hình 2.2:
- IVFMD Mobile app: Phần mềm đặt lịch hẹn khám Nền tảng sử dụng: Mobile và Web App Mô tả chi tiết: Có thể ngồi tại nhà, bệnh nhân đăng ký tài khoản và sử dụng app để đặt lịch hẹn khám, bộ phận CRM – Frontline sẽ chăm sóc nhóm bệnh nhân đặt trước này để xác nhận lịch hẹn
Hình 2.2 Sơ đồ mô tả các ứng dụng thông tin theo quy trình khám hiếm muộn
- IVFMD Patient Declaration: Phần mềm khai báo thông tin bệnh nhân Nền tảng sử dụng: Web Application Mô tả chi tiết: Bệnh nhân đến quầy nhận bệnh, sẽ thực hiện nhập thông tin theo mẫu trong trường hợp chưa có thông tin trên hệ thống Bộ phận Frontline chịu trách nhiệm hỗ trợ
- IVFMDSmart: Phần mềm quản khám lý tại Đơn vị hỗ trợ sinh sản Nền tảng sử dụng: Desktop Application Mô tả chi tiết: Bệnh nhân sẽ được ghi nhận thông tin khám trên phần mềm IVFMDSmart Trong phòng khám, các bác sĩ,
8 nữ hộ sinh, thư ký y khoa thực hiện nhập thông tin khám, cho chỉ định dịch vụ, điều trị, giấy giới thiệu…
- IVFMDImaging: Phần mềm lưu trữ và truyền tải hình ảnh siêu âm Nền tảng sử dụng: Desktop Application Mô tả chi tiết: Tại phòng siêu âm, bác sĩ thực hiện các chẩn đoán qua hình ảnh cho bệnh nhân, kết quả siêu âm được lưu trữ vào hệ thống
- IVFMD Document Management app: Phần mềm sao chụp hồ sơ Nền tảng sử dụng: Tablet application Mô tả chi tiết: Các giấy tờ pháp lý, kết quả y tế của bệnh nhân sẽ được số hóa bằng phần mềm sao chụp, nhân viên y tế (bác sĩ, nữ hộ sinh) có thể xem lại khi cần tại bất kỳ vị trí nào
- IVFMD Injection Management app: Phần mềm quản lý tiêm thuốc HTSS Nền tảng sử dụng: Tablet Application Mô tả chi tiết: Trong quá trình điều trị, bệnh nhân sẽ được quản lý lịch tiêm thuốc hỗ trợ sinh sản bằng phần mềm, giúp đảm bảo tiêm đúng theo phác đồ và loại thuốc tại phòng tiêm của bệnh viện
- IVFMD Patient Identification app: Phần mềm nhận diện bệnh nhân phòng lưu bệnh Nền tảng sử dung: Mobile Application Mô tả chi tiết: Khi bệnh nhân chuẩn bị thủ thuật, tại phòng lưu bệnh, bệnh nhân sẽ được Hộ lý/ Nữ hộ sinh thực hiện nhận diện bệnh nhân qua thẻ đeo để đối chiếu thông tin, loại thủ thuật đảm bảo tính an toàn
- IVFMD Patient Identification: Phần mềm nhận diện bệnh nhân phòng thủ thuật Nền tảng sử dụng: Desktop Application Mô tả chi tiết: Trước khi bắt đầu thủ thuật, bệnh nhân được xác nhận với nhân viên y tế (NHS, Bác sĩ) về thông tin thủ thuật trước khi thực hiện, bao gồm cả thông tin (hình phôi) trước khi được chuyển
- IVFMDLabo: Phần mềm theo dõi phôi Nền tảng sử dụng: Desktop Application Mô tả chi tiết: Trong phòng labo, điều kiện vô trùng, các chuyên viên phôi học sử dụng máy tính bảng để ghi nhận toàn bộ quy trình nuôi cấy, trữ lạnh và rã phôi của bệnh nhân
Mô tả các tính đặc thù của dữ liệu y tế
2.2.1 Dữ liệu bị phân tán và khác biệt về cấu trúc dữ liệu giữa các cơ sở y tế
Dữ liệu y tế được số hóa có tiềm năng rất lớn đối với hệ thống sức khỏe hiện nay Các thông tin được số hóa bao gồm các chẩn đoán của người bệnh, lịch thăm khám, điều trì và cả các xét nghiệm, chẩn đoán hình ảnh của bệnh nhân Tuy nhiên, dữ liệu số hóa này đang tồn tại ở rất nhiều cấu trúc khác nhau do được quản lý bởi các phần mềm khác nhau tại các cơ sở y khoa, dẫn đến dữ liệu y tế được số hóa không thể dùng để tương tác giữa các hệ thống [5] Thực vậy, người bệnh thực hiện rất nhiều các điều trị ở các trung tâm y tế khác nhau, vậy nên, việc dữ liệu điều trị được lưu trữ phân tán khắp nơi tại các cơ sở y tế Điều này dẫn đến một kết cục đang buồn, chính là kết quả điều trị của người bệnh sẽ kém hiệu quả và mang đến một trải nghiệm không tốt khi tham gia vào hệ thống chăm sóc sức khỏe vì thiếu liền mạch Các nhân viên y tế cũng cảm thấy khó khăn hơn rất nhiều khi không thấy được toàn bộ lịch sử khi thực hiện điều trị cho bệnh nhân Và tất yếu, các chỉ định không cần thiết về cận lâm sàng sẽ không được sàng lọc, gây lãng phí cho hệ thống chăm sóc sức khỏe và chính bệnh nhân
Các nghiên cứu đã chỉ ra rằng, việc chia sẻ dữ liệu điều trị của bệnh nhân sẽ tăng đáng kể về hiệu quả điều trị và giảm nguy cơ sai sót khi thực hiện một liều trình điều trị mới Bên cạnh đó, sự gia tăng của khám bệnh từ xa gần đây rất đáng kể, từ đó gia tăng nhu cầu về một mô hình chưa sẻ dữ liệu bệnh nhân được an toàn và hiệu quả Hiện nay, tại Việt Nam chưa triển khai được một mô hình chia sẻ dữ liệu giữa các cơ sở y tế từ cấp nhỏ đến lớn nhất Để thực hiện được điều này cần sự tham gia từ phía chính quyền, tìm kiếm sự ủng hộ từ các nhà ban hành luật cũng như nhận thức được tồn tại của hệ thống dữ liệu y tế hiện nay Nếu cứ tiếp tục thả lỏng việc số hóa dữ liệu một cách không có chiến lược cụ thể, thì việc dữ liệu có thể sử dụng để tương tác giữa các hệ sẽ khó thực hiện được
Khó khăn này không chỉ tồn tại ở Việt Nam mà còn phổ biến ở các quốc gia phát triển Điển hình là tình trạng thiếu tương tác giữa các hệ thống EMR ở nước này Chính quyền Canada đã tiêu tốn khoản 1,2 tỷ đô-la Mỹ để thành lập trung tâm sức khỏe quốc gia Canada, bộ phận đang giao trách nhiệm phát triển hệ thống EMR cho đất nước Họ phối hợp với các tổ chức học thuật, để đưa ra các hướng dẫn khi triển khai EMR tại các hệ thống chăm sóc khỏe liên bang Tuy nhiên, do việc chấp thuận sử dụng EMR tại mỗi bang lại khác biệt nhau nên tình trạng
11 thiếu một tiêu chuẩn chung vẫn không giải quyết được Dữ liệu y tế vẫn rơi vào tình trạng phân tán và thiếu tính kết nối
2.2.2 Tính chính xác và toàn vẹn của dữ liệu
Rất nhiều công nghê mới được đề xuất để giải quyết vấn đề này, nhưng vẫn còn vấp phải sự bảo thủ của một số đông nhân viên y tế Rất nhiều chuyên gia y tế không tin vào kết quả của dữ liệu trên máy tính và máy tính bảng được cung cấp cho họ, thay vào đó họ tin vào các ghi chép cá nhân của mình bằng viết và giấy Chính vì thế dữ liệu y tế luôn trong tình trạng đối mặt với nguy cơ bị mất dữ liệu, gặp các lỗi về kỹ thuật của máy tính và là chủ đề bảo mật luôn được nhắc tới khi đem ra thảo luận giữa các hội đồng số hóa dữ liệu y tế [6] Bên cạnh đó, cũng có rất nhiều nhà quản lý các cơ sở y tế quyết định dấn tới trong việc triển khai hồ sơ y tế điện tử EMR, tuy vậy, cũng rất nhiều chuyên gia y tế gặp khó khăn trong việc làm quen với phần mềm và sử dụng chúng đúng cách, từ đó họ lại muốn quay về với công cụ vốn dĩ quen thuộc từ bao năm qua: viết và giấy Các thất bại này dẫn tới tiêu tốn rất nhiều nguồn lực và dẫn tới phát sinh lượng dữ liệu không sử dụng được và nhiều lỗi
Các nhà chức trách luôn mong muốn một viễn cảnh có thể quản lý dữ liệu điện tử của người dân một cách thuận tiện Ở đó, các bên tham gia trong ngành chăm sóc sức khỏe có thể chia sẻ dữ liệu cho nhau một cách dễ dàng hơn, minh bạch hơn và có độ tin cậy cao Từ đó bệnh nhân cũng có thể tham gia một phần vào việc quản lý dữ liệu sức khỏe cá nhân của mình Các chuyên gia tin rằng với các công nghệ mới hiện nay thì tính toàn vẹn của dữ liệu, khả năng chống can thiệp chỉnh sửa, dữ liệu có độ tin cậy cao và không cần thêm sự giám sát của các bên thứ ba sẽ sớm được thực hiện trong tương lai sắp tới
2.2.3 Tính bảo mật trong dữ liệu y tế
Dữ liệu y tế của bệnh nhân có thể bao gồm các dữ liệu trong nghiên cứu thử nghiệm lâm sàng, và bệnh sử trong hợp đồng bảo hiểm, cũng như các dữ liệu được tạo ra từ các thiết bị chăm sóc sức khỏe Các dữ liệu này tập trung phát sinh liên tục trong quá trình điều trị tại các cơ sở y tế Tùy vào loại dữ liệu điện tử mà cấp độ về bảo mật dữ liệu được yêu cầu cam kết khác nhau
Ngược lại, một số thông tin không nhầm định danh một cá nhân cụ thể thì có mức bảo mật tháp hơn như là giới tính, tuổi, thói quen ăn uống và tình trạng vận động Các dữ liệu này không quá nhạy cảm để có thể chia sẻ với các tổ chức mong muốn được tiếp cận với nguồn dữ liệu sức khỏe [7] Chính vì thế, việc phân tách thành các cấp độ bảo mật cho dữ liệu y tế là tối cần thiết, đây cũng là cơ sở để phân loại các loại dữ liệu khác nhau trong cấu trúc của một bệnh án điện tử Các chuyên gia gợi ý việc phân mức độ bảo mật của dữ liệu theo: độ nhạy cảm của dữ liệu, đánh giá khả năng cần tiếp cận và nhu cầu cần được bảo mật theo từng cấp độ người dùng Từ đó có thể tạm chia thành ba nhãn cấp bậc cho dữ liệu y tế như sau: Cần được bảo mật, trung bình và thấp Chi tiết theo Bảng
2.1, là các loại dữ liệu có trong bệnh án điện tử và được gán nhãn cấp độ bảo mật
Bảng 2.1 Các mức độ bảo mật dữ liệu được phân loại trong một bệnh án điện tử
2.2.4 Sự khởi đầu của công cuộc trao đổi dữ liệu y tế
Chính việc triển khai hồ sơ sức khỏe điện tử đóng vai trò quan trong trong công tác thúc đẩy hình thành trao đổi dữ liệu Đã từng có sự triển khai rộng lớn trong các tổ chức sức khỏe quanh đối với hồ sơ sức khỏe điện tử trên toàn lãnh thổ nước Mỹ do đạo luật HITECH (Health Information Technology for Economic and Clinical Health) ban hành năm 2009 Nhưng bản thân đạo luật này lại thiếu đi tính nhất quán giữa các hệ thống y tế Đã từng có sự thảo luận trong hội đồng liên bang tại Mỹ về chủ đề sử dụng hiệu quả nguồn dữ liệu y tế, đồng thời xúc tiến trao đổi dữ liệu giữa các hệ thống y khoa, tuy nhiên nỗ lực này lại không được tiến hành mạnh mẽ Điểm thiếu sót chính là các hướng dẫn được ban hành mô tả rất thiếu chi tiết về các tiêu chuẩn đề ra, từ đó dẫn đến các tổ chức y tế tiến hành thực hiện theo nhiều phương pháp khác nhau để có thể đáp ứng được yêu cầu Bên cạnh đó, một số tổ chức y tế lớn lại dành nguồn lực để thúc đẩy trao đổi dữ liệu trong bản thân hệ thống của họ nhiều hơn, khoản cách về thông tin lại ngày càng được gia tăng giữa các hệ thống y tế lớn
Việc triển khai gặp nhiều khó khăn, thế nhưng, đã có một số ít các tổ chức sức khỏe đáng tin cậy đã thực hiện trao đổi dữ liệu y tế theo mô hình hiện đại, cụ thể là họ thực hiện trao đổi các dữ liệu lâm sàng của bệnh nhân trên dữ liệu đã được số hóa Một mô hình trao đổi dữ liệu y tế hiện đại được định nghĩa trên cơ sở dữ liệu được điện tử hóa bao gồm các dữ liệu về ghi chép lâm sàng, các kết quản xét nghiệm và cả dữ liệu chưa được cấu trúc rõ ràng Cấp độ tiến hành của các mô hình trao đổi này phụ thuộc rất lớn vào hệ thống công nghệ của các tổ chức khỏe tham gia vào Điển hình như vùng vịn biển California tại Mỹ đã tiên phong thành lập mạng lưới trao đổi dữ liệu vùng Họ thiết lập một tiêu chuẩn cho độ tin cậy về
13 dữ liệu cho các tổ chức muốn tham gia vào, còn tiêu chuẩn cho loại dữ liệu thì vẫn còn đang được tiến hành vào giai đoạn sau
Trái ngược với các mô hình trao đổi dữ liệu sức khỏe hiện đại, thì một mô hình trao đổi truyền thống là các dữ liệu y tế được trao đổi không được số hóa, phần lớn sẽ là các bản ghi chép được ký gửi hoặc là bản tóm tắt bệnh án, các bản sao chép kết quả xét nghiệm, từ đó nơi nhận sẽ ghi chép lại các kết quả nhận được trên Như đã trình bày ở phía trên, chính những rào cản trong nguồn lực công nghệ thông tin sức khỏe, mà các tổ chức thường ưu tiên triển khai trao đổi dữ liệu bằng các bản in tóm tắt được chuyển phát nhanh Một số tổ chức khác còn không đủ khả năng để có thể tiếp nhận các dữ liêu y tế được số hóa, bởi vì họ chưa thể tổ chức để lưu trữ khối lượng dữ liệu được gửi đến Theo một thống kê của Everson, các thông tin số hóa được truy xuất từ bên ngoài hệ thống chỉ có thể sử dụng được 55% và được tổ chức cấu trúc rất kém để có thể hiểu được
Nhiều giải pháp công nghệ đã được đưa ra để giải quyết những tồn động cho mô hình trao đổi dữ liệu hiện đại, tuy nhiên các giải pháp này được đánh giá khả thi cao nhưng triển khai như một tiêu chuẩn chung thì lại thất bại Có quá nhiều sự tùy chỉnh liên quan đến độ lớn, cũng như nguồn lực để đáp ứng quá tốn kém đối với một tổ chức sức khỏe, chỉ để tham gia vào mô hình trao đổi dữ liệu hiện đại Bên cạnh đó là thiếu sự đồng thuận từ cấp độ quốc gia đối với các tổ chức khi thực hiện triển khai trao đỗi dữ liệu với nhau Từ đó, cũng thấy được lúc đó, các nhà cầm quyền cũng gặp phải sự lúng túng và mơ hồ trong việc lập kế hoạch và thực thi nó trên phạm vi toàn quốc Vào tháng 4 năm 2021, ông Micky Trpathi, điều phối viên của tổ chức thông tin sức khỏe quốc gia của Mỹ đã phát động một lần nữa để kêu gọi thực thi chuyển đổi toàn bộ các ghi chép giấy, diễn giải y khoa và các dữ liệu phi cấu trúc thành một tiêu chuẩn chung thông công nghệ học máy và xử lý ngôn ngữ tự nhiện Ông cũng đề ra một tương lai tích cực cho người bệnh rằng họ có thể tự do quyết định trên cơ sở dữ liệu y tế của mình, khi họ có nhu cầu chia sẻ chúng cho một tổ chức sức khỏe nào đó.
Công nghệ chuỗi khối – Blockchain
2.3.1 Các đặc điểm chính của công nghệ chuỗi khối
Theo kết quả công bố tại tạp chí Khoa học và công nghệ, công nghệ chuỗi khối có những đặc trưng sau [8]:
- Một cơ sở dữ liệu phân tán
Thông tin tổ chức trên một blockchain được tồn tại dưới dạng cơ sở dữ liệu (CSDL) phân tán CSDL blockchain không được lưu trữ ở duy nhất một vị trí nào mà được lưu trú trên các block của hệ thống nhưng có liên kết logic với nhau một cách công khai, dễ kiểm chứng Không có một phiên bản tập trung nào của CSDL này tồn tại, nên hacker cũng chẳng có cơ hội nào để tấn công nó Về mặt vật lý, CSDL của blockchain được lưu trú bởi hàng triệu máy tính cùng lúc, dữ liệu của nó có thể truy cập bởi bất cứ người nào trên Internet
Cơ sở dữ liệu phi tập trung phân chia khối lượng công việc trên nhiều máy tính và sử dụng các thuật toán phức tạp để cân bằng các yêu cầu gửi đến và gửi đi để có thời gian phản hồi tốt nhất Loại cơ sở dữ liệu này rất hữu ích khi có nhu cầu lưu trữ nhiều dữ liệu trong cơ sở dữ liệu hơn là có thể được lưu trữ vật lý trên một máy tính vật lý Các bit – như tệp nhật ký, dữ liệu được ghi lại bằng cách theo dõi các lần nhấp qua trong ứng dụng và dữ liệu được tạo ra bởi Internet of Things – chồng chất và cần được lưu trữ ở đâu đó Chúng cũng thường được gọi là cơ sở dữ liệu phân tán
Chúng ta có sự phân biệt khác nhau giữa hai khái niệm này qua định nghĩa của nó [9]:
Dữ liệu phi tập trung: Không tồn tại hệ thống lưu trữ tập trung, Các máy chủ lưu trữ dữ liệu khác nhau đều có quyền ghi chép và có thể cùng cung cấp dữ liệu, và các máy chủ đều phải trong trạng thái kết nối với nhau như mô tả ở Hình 2.3
Hình 2.3 Mô tả hệ thống lưu trữ phi tập trung
Dữ liệu phân tán: là hệ thống lưu trữ trên nhiều máy chủ khác nhau, quyền kiểm soát vẫn mang tính tập trung
Tính phi tập trung thường bị nhầm lẫn là chỉ dừng lại ở việc lưu trữ dữ liệu ở nhiều nơi Theo anh Nguyễn Việt Dinh - Admin nhóm Diễn đàn phổ cập Blockchain: “Vậy đặc tính phi tập trung (Decentralized) được thể hiện ở 2 khía cạnh trong 1 hệ thống blockchain: 1 Việc xác nhận các giao dịch (tạo block); 2 Việc thiết lập, thay đổi giao thức đồng thuận.”
- Tính bền vững của chuỗi khối
Bằng cách lưu trữ những khối thông tin giống nhau trên mạng lưới của mình, do đó blockchain không thể: - Bị kiểm soát bởi bất kỳ một thực thể nào; - Không có
15 điểm thiếu sót hoặc lỗi duy nhất nào Blockchain - giải pháp truy xuất nguồn gốc bằng cấp
- Minh bạch và không thể bị phá vỡ
Mạng lưới blockchain tồn tại trong trạng thái của sự thỏa thuận, tự động kiểm tra
10 phút một lần Một loại hệ sinh thái tự kiểm soát giá trị kỹ thuật số, mạng lưới sẽ điều hòa mọi giao dịch xảy ra trong khoảng 10 phút Mỗi nhóm giao dịch này được gọi là khối Hai đặc tính quan trong được rút ra từ đây: - Minh bạch: Dữ liệu được nhúng trong mạng như một khối, công khai; - Không thể bị hỏng: Khi thay đổi bất kỳ đơn vị thông tin nào trên blockchain có nghĩa là phải sử dụng một số lượng lớn máy tính để ghi đè thông tin lên toàn bộ mạng
- Một mạng lưới các nút
Một mạng lưới các nút tính toán tạo thành blockchain là các máy tính được kết nối với mạng với nhau, sử dụng client để thực hiện nhiệm vụ xác nhận và chuyển tiếp các giao dịch Nút sẽ nhận được một bản sao của blockchain, được tải tự động khi tham gia mạng lưới blockchain Các nút này cùng nhau tạo ra một mạng lưới cấp 2 mạnh mẽ, một góc nhìn hoàn toàn khác về cách mà Internet có thể hoạt động Mỗi nút là một “quản trị viên” của mạng blockchain và tự động tham gia vào mạng
Theo thiết kế, blockchain là một công nghệ được phân quyền Bất cứ điều gì xảy ra trên đó đều là chức năng của mạng Nhờ tạo ra cách mới để xác nhận giao dịch mà những khía cạnh của thương mại truyền thống có thể trở nên không cần thiết
Ví dụ như những giao dịch trên thị trường chứng khoán có thể thực hiện cùng lúc trên Blockchain, hoặc có thể lưu trữ tài liệu giống như sổ đỏ, hoàn toàn công khai Và sự phân quyền đã trở thành hiện thực
Nhờ lưu trữ dữ liệu trên mạng của mình, blockchain loại bỏ những rủi ro đi kèm với dữ liệu được tổ chức tập trung Trên Internet thì chúng ta dựa vào hệ thống username/password để bảo vệ danh tính và tài sản của mình trên mạng, nhưng với cách làm này hệ thống vẫn có nhiều khả năng bị rủi ro Còn phương pháp bảo mật của blockchain sử dụng công nghệ mã hóa với cặp khóa public/private Khóa public (một chuỗi dài các số ngẫu nhiên) là địa chỉ của người dùng trên blockchain Khóa private giống như mật khẩu, cho phép chủ sở hữu truy cập vào giao dịch hoặc các tài sản kỹ thuật số khác
2.3.2 Sơ lược về hợp đồng thông minh
Hợp đồng thông minh (tiếng anh: Smart Contract, viết tắt SC) còn được biết đến với tên gọi “hợp đồng ảo” và có lịch sử phát triển tương đối phức tạp Trước đây,
SC đã từng được định nghĩa hết sức đơn giản là những hợp đồng mà việc thực hiện các nội dung hợp đồng được tiến hành một cách tự động, hay là những thuật toán thực thi các điều khoản hợp đồng thông qua hệ thống máy tính [10]
Tuy nhiên, các định nghĩa này đã khiến giới nghiên cứu bối rối trong việc phân biệt SC trên nền tảng Blockchain ngày nay với dạng SC thông thường ẩn chứa trong hoạt động của các máy bán hàng tự động, trong các giao dịch hàng ngày hàng giờ diễn ra trên thị trường ngoại hối hay thị trường chứng khoán, vốn dĩ xuất hiện từ rất lâu trong đời sống con người Ví dụ đơn giản nhất của dạng thức
SC này chính là hoạt động của máy bán hàng tự động Bên mua sẽ thanh toán bằng cách nạp tiền vào “đầu nhận tiền” của máy, hệ thống xử lý của máy sẽ kiểm tra số tiền máy đã nhận và kích hoạt những “món hàng” tương thích với số tiền mà người mua đã nạp Nếu người mua chọn lựa trong số những món hàng khả dụng với số tiền đó thì hợp đồng được thực thi và ngược lại, sẽ bị từ chối Như vậy, hợp đồng này đã được tự động hóa việc thực thi khi các điều kiện được thỏa mãn nhờ một chương trình máy tính [9]
2.3.3 Ưu thế của Hợp đồng thông minh
Thứ nhất, SC không có sự phụ thuộc vào bên thứ ba đối với việc thi hành hợp đồng Việc loại bỏ bên trung gian sẽ làm giảm đáng kể tổng số tiền phải chi cho việc thực hiện hợp đồng Loại bỏ các nhà cung cấp bên thứ ba cũng có nghĩa là toàn bộ quá trình xác nhận và thực thi hợp đồng trở nên nhanh chóng khi người dùng trực tiếp giao dịch với nhau Ngoài ra, SC còn loại bỏ được các phản ứng thông thường như ngừng giao dịch, yêu cầu bồi hoàn hay liên hệ với các đơn vị trung gian [11]
Các nền tảng công nghệ chuỗi khối hiện nay
2.4.1 So sánh các nền tảng ứng dụng chuỗi khối
Trong các nghiên cứu được công bố gần đây khi phát triển ứng dụng chuỗi khối trong y tế, có hai nền tảng chính được sử dụng để phát triển ứng dụng chính là: nền tảng Ethereum và Hyperledger Fabric Ngoài ra, nền tảng Bitcoin cũng được đưa vào so sánh với nhau trên các khía cạnh cần cho một hệ thống thông tin Đây chính là những thông tin cần thiết để các nhà phát triển và nghiên cứu có thể dựa vào để chọn nền tảng chuỗi khối phù hợp với công việc của mình [22]
Trong ứng dụng phát triển các giải pháp trong y tế, thì công nghệ bitcoin có phần lép vế hơn vì bị giới hạn chủ yếu vì lưu thông giao dịch trên chuỗi Chính việc không giới hạn số điểm tham gia vào chuỗi để thực hiện tham gia đào, đã ảnh hưởng đến khả năng mở rộng, cũng như là tốc độ và thông lượng số giao dịch có thể thực hiện Hạn chế này cũng bởi một phần do cơ chế đồng thuận của chính bản thân nền tảng bitcoin là PoW (Proof of Word) Có thể hình dung như sau, nếu một lệnh mã hóa bắt đầu với 30 kí tự số 0 ở đầu, thì sẽ có tới tận gần một tỷ khả năng để đoán ra số ‘nonce’ Bài toán tìm ra số nonce sẽ tốn rất nhiều tài nguyên tính toán, từ đó dẫn tới tốn nhiều chi phí vận hành Phần thưởng tiền số trên chuỗi chính là phần thưởng để các điểm trên chuỗi đánh đổi chi phí vận hành tham gia vào công cuộc tìm ra số nonce
Tuy vậy, như đã từng đề cập ở phần trước, các nhà phát triển chọn phát triển các ứng dụng y tế trên các nền tảng chuỗi khối không cần phải tốn các chi phí khi vận hành quá nhiều Bảng 3 đem đến thông tin chi tiết cho các so sánh được thực hiện với nền tảng Bitcoin Ta có thể nhận xét rằng có một hạn chế nữa của nền tảng Bitcoin những cũng không thiếu phần quan trọng, đó là lập trình viên không thể thực hiện các hợp đồng thông minh vào chuỗi khối, tính năng không thể thiếu trên các ứng dụng sức khỏe hiện nay Chính vì những yếu tố kể trên, nên sẽ dễ hiểu được lý do tại sao lại không thấy các sản phẩm sức khỏe được phát triển trên nền tảng Bitcoin cũng như các nền tảng chuỗi khối thuộc thế hệ đầu tiên
Như vậy, trong việc suy xét các nền tảng công nghệ chuỗi khối sẵn có, thế hệ tiếp theo là Ethereum vẫn có những hạn chế nhất định, nhưng vẫn có thể được sử dụng để phát triển các mạng được cấp quyền và thực thi đươc hợp đồng thông minh Một cách chi tiết thì nền tảng Ethereum vẫn có những đặc điểm tương tự như Bitcoin như là: các điểm vẫn tham gia vào xác nhận trong chuỗi và nhận phần thưởng là tiền mã hóa với tên Ether; Ethereum vẫn có khả năng chống lại tấn công khi cần sự đồng thuận với 51% và cơ chế đồng thuận là PoW (nguyên nhân dẫn đến thông lượng giao dịch vị giới hạn và tốn nhiều chi phí khi vận hành nó) Thêm vào đó, hợp đồng thông minh trên chuỗi Ehtereum chỉ có thể được viết bằng ngôn ngữ lập trình bậc cao Solidity Chính giới hạn này dẫn đến các nhà phát triển ứng dụng bắt buộc phải học thêm một ngôn ngữ lập trình mới có thể phát triển ứng dụng mong muốn
Bảng 2.2 Bảng tóm tắt các điểm khác biệt giữa các nền tảng chuỗi khối trong việc phát triển ứng dụng sức khỏe
So với với hai nền tảng kể trên thì Hyperledger Fabric là một giải pháp đơn giản hơn rất nhiều cho các nhà phát triển Đặc biệt hơn là nền tảng này cung cấp thêm các giải pháp đãm bảo tính riêng tư và bảo mật cho hệ thống: kiểm soát truy cập chi tiết, các kênh giao tiếp riêng giữa các điểm và phương pháp mã hóa Zero- knowledge Các nhà phát triển ứng dụng có nhiều công cụ hơn rất nhiều để thực hiện thêm giải pháp bảo mật cho hệ thống Và tất nhiên, Hyberledger Fabric có cả tính năng thực thi hợp đồng thông minh, điểm khác biệt là không dựa vào các giao thức nặng về tính toán đòi hỏi rất nặng về khả năng tính toán nữa Một điểm cộng thêm là Fabric không sử dụng đơn vị tiền mã hóa như là phần thưởng khích lệ khi xác nhận giao dịch Một ưu thế rất mạnh mà Fabric còn sở hữu đó chính là ngôn ngữ lập trình hợp đồng thông minh không còn bị giới hạn như Ethereum mà thay vào đó có thể được thực hiện bởi nhiều ngôn ngữ lập trình mới gần đây như Javascript, Java, Go và Typescript Với các ưu điểm trên đã đưa Hyberledger Fabric trở thành một nền tảng ưu tiên khi thực hiện một dự án phát triển ứng dụng sức khỏe
2.4.2 Giới thiệu nền tảng công nghệ chuỗi khối Hyperledger fabric
Lunix Foundation đã thành lập dự án Hyberledger vào năm 2015 để tăng khả năng ứng dụng công nghệ chuỗi khối vào các nền công nghiệp khác Nền tảng Hyperledger Fabric là một trong những sản phẩm trong dự án Hyperledger Với sự đóng góp của công ty IBM, Hyperledger Fabric đã bứt phá và trở thành một torng những nền tảng chuỗi khối nổi trội nhất tới hiện nay Hyperledger Fabric được biết tới như một mạng lưới chuỗi khối được kiểm soát hoàn toàn, một hệ thống được thiết kế phù hợp với các dữ liệu nhạy cảm và cần có tính bảo mật cao Các tính năng trên được IBM giới thiệu chi tiết qua Hình 2.6, được đăng chi tiết trên trang chủ giới thiệu về sản phẩm Hyperledger Fabric
Hình 2.6 Các điểm nổi bật của nền tảng Hyperledger Fabric
So với những nền tảng khác, sản phẩm Hyperdedger được đánh giá là một giải pháp phù hợp để phát triển các ứng dụng dành cho y tế [23] Một số khía cạnh nổi trổi của Fabric có thể kể đến:
• Quản lý truy cập: hệ thống có thể quản lý toàn bộ đối tượng và xác thực bất kỳ tài khoản người dùng nào truy cập vào hệ thống
• Đảm bảo tính bảo và riêng tư: Cho phép thực hiện các giao dịch bí mật riêng trên cùng một mạng lưới đã thiết lập
• Xử lý các giao dịch hiệu quả: Khả năng thực hiện các giao dịch được tách thành các tác vụ sắp xếp các giao dịch và xác nhận
• Hợp đồng thông minh linh hoạt: các ràng buộc có thể được mã hóa và thực thi theo từng loại giao dịch Hệ thống hợp đồng thông minh có thể tham gia định nghĩa các thông số hệ thống trên phạm vi toàn bộ kênh giao tiếp
• Thiết kế lắp ghép: Hệ thống cho phép triển khai theo kiến trúc lắp ghép để có thể linh hoạt quyết định theo từng chức năng và ý tưởng của người thiết kế
2.4.3 Các thành phần chính trong Hyperledger Fabric
Với khả năng tùy chỉnh của mình, nền tảng hyperledger fabric cũng có rất nhiều thành phần để các nhà phát triển có thể tùy chỉnh cho phủ hợp với giải pháp của mình [24],[25]:
- Tài sản (asset): Tài sản ở đây có thể hiểu rộngC ra ở tính hữu hình như là
(bất động sản và thiết bị) hoặc có thể vô hình (như là sở hữu trí tuệ và các hợp đồng có giá trị) Hyperledger Fabric cho phép thực hiện tùy chỉnh các thuộc tính của tài sản rồi sau đó được dùng trong các giao dịch trên chuỗi
- Hợp đồng thông minh (chaincode): là các chỉ dẫn để có thể điều chỉnh tài sản trên hệ thống, có thể nó rằng nó còn là nguyên tác nghiệp vụ được thực
25 hiện khi đưa vào ứng dụng thực tế Hợp đồng thông minh có chức năng ghi nhận vào sổ cái và được thông qua khi giao dịch được xác thực hợp lệ Các trình tự thực hiện được xác thực qua cặp giá trị ID – và các biến đi cùng, các gặp giá trị - biến số này được được vào hệ thống và cần dược đồng ý bởi các điểm tham gia trên chuỗi
- Sổ cái (Ledger): là nơi ghi nhận tất cả kết quả, các thay đổi xảy ra trong fabric Các thay đổi này chính là kết quả thực hiện dựa theo hợp đồng thông minh đã được đồng thuận giữa các tổ chức trong chuỗi Trong fabric, tồn tại ở mỗi kênh giao tiếp có một sổ cái khác nhau Các thành phần khi truy cập, tùy theo giới hạn quyền của mình mà có quyền đọc, ghi mới, chỉnh sửa vào sổ cái
- Chính sách (Policy): Chính nhờ vào thiết lập chính sách đã khiến nền tảng Hyperledger khác biệt với các nền tảng Ethereum và Bitcoin Chính sách giúp nhà phát triển thiết lập các tổ chức nào có thể truy cập và cập nhật dữ liệu vào mạng lưới Thậm chí các nhà phát triển có thể quy định số lượng các tổ chức đồng ý trước khi một đề xuất cập nhật được thông qua Các chính sách cũng có nhiều cấp độ trong nền tảng Fabric (cấp hệ thống, cấp ứng dụng và cấp kiểm soát truy cập, hợp đồng thông minh) Chính việc cấp nhật chính sách cũng có thể cấu hình riêng cho từng kênh được triển khai bởi người quản trị kênh
Các đề tài ứng dụng chuỗi khối đã thực hiện trong lĩnh vực y tế
2.5.1 Ứng dụng chuỗi khối cho việc bảo tồn sinh sản trong thành phố thông minh Để giải quyết các vấn đề về việc ngày càng giảm về khả năng sinh sản của người thành thị Tác giả Ndzimakhwe [26], đã đề xuất một mô hình ứng chuỗi khối để nâng cao khả năng truy xuất mẫu trữ lạnh sinh sản và hỗ trợ sinh sản
Hình 2.7 Mô tả về mô hình ứng dụng chuỗi khối liên kết cho ngân hàng noãn của tác giả Da-Yin Liao
Cụ thể tác giả Ndzimakhwe trình bày một mô hình về ngân hàng noãn có ứng dụng chuỗi khối ở Hình 2.7 Hệ thống có thể ghi lại toàn bộ lịch sử của quá trình chọc hút trứng, đến thụ tinh (nếu trứng nó may mắn phát triển đến cuối cùng) Trong chuỗi sẽ tạo ra một khối dữ liệu mới vào chuỗi nếu có một quá trình mới được hình thành Như vậy, mỗi khối trong chuỗi sẽ chứa một phần mô tả và nội dung Phần mô tả là tiêu đề chứa đoạn mã hóa từ các khối trước Phần nội dung chứa toàn bộ nội dung của quá trình được phát sinh
Tóm lại, có thể mô tả tuần tự hoạt động của hệ thống như sau:
1 Người dùng trong chuỗi sẽ tạo một yêu cầu tới nhà quản lý để phát sinh một bộ thông tin cho noãn
2 Nhà quản lý truyền đi thông tin của yêu cầu vào một khối
3 Nhà quản lý gửi bộ dữ liệu từ khối đã tạo vào hệ thống chuỗi khối phân tán
4 Toàn bộ các nhà quản lý trong chuỗi xác nhận khối mới và chuyển tiếp bộ thông tin này qua cho nhàn quản lý khác
5 Các nhà quản lý sẽ cùng nhau đat tới một đồng thuận mới cho chuỗi
6 Khối mới được chính thức thêm vào chuỗi Đối với người dùng đơn lẻ sẽ cập nhật bản sao vào bộ nhớ
2.5.2 Ứng dụng chuỗi khối để truy dấu mẫu tinh trùng Eggschain
Wei Escala là nhà sáng lập và điều hành công ty Eggschain, một công ty khởi nghiệp ở nước Áo để cung cấp giải pháp trong ngành hỗ trợ sinh sản Trong đó Eggchain là một sản phẩm được xcây dựng dựa trên Bitcoin và công ty Stacks (một công ty công nghệ ứng dụng chuỗi khối và hợp đồng thông minh) [27] Với giải pháp này, mỗi khi người hiến tinh trùng đưa mẫu vào hệ thống đồng thời sẽ ghi nhận vào chuỗi khối với đầy đủ thông tin thời gian Qua cách này, mỗi lần sử dụng mẫu cũng được ghi lại, đều này tạo cơ hội cho người hiến theo dõi mẫu của mình được sử dụng như thế nào Ngoài ra, giải pháp còn tạo hội cho người hiến tinh trùng trao đổi với người một cách ẩn danh, trường hợp họ muốn giấu thông tin nhân thân [28]
Gần đây, công ty Eggschain đã tiến hành hợp tác với chuỗi phòng khám hỗ trợ sinh Boston IVF (Hình 2.8) Đây là một trong những chuỗi phòng khám lâu đời nhất, thành lập từ 1986 và đã hỗ trợ cho ra đời hơn 100,000 đứa trẻ Sự hợp tác này mong đợi sẽ mang một giải pháp hoàn thiện cho việc truy vết mẫu tinh trùng, và các vật chất di truyền khác Hai bên kì vọng đây sẽ là cơ hội giải quyết các vấn đề tồn đọng trong việc vận động hiến noãn và tinh trùng, một giải pháp hoàn toàn minh bạch
Hình 2.8 Công ty giải pháp chuỗi khối Eggschain và Chuỗi phòng khám
2.5.3 Ứng dụng hợp đồng thông minh trong trao đổi dữ liệu y tế Đã nhiều báo cáo trình bày một giải pháp tăng cường bảo mật khi trao đổi dữ liệu ye tế, một mô hình đề xuất dựa trên công nghệ chuỗi khối [29] Mục đích là muốn tạo ra một môi trường minh bạch, an toàn cho người bệnh tham gia chia sẻ dữ liệu Trong báo cáo, tác giả đưa ra giải pháp chuỗi khối kết hợp để tăng tính truy vết và các khối dữ liệu an toàn Dữ liệu bệnh nhân được tạo ra và truyền đi dựa trên chuẩn dữ liệu Health Level-7 Fast Healthcare Resource (FHIR), hiện đang được dùng rộng rãi trong trao đổi dữ liệu y tế
Ngoài ra, bản thân bệnh nhân khi tham gia vào chuỗi cũng có khóa riêng tư và khóa công khai để trao đỗi dữ liệu Khóa công khai vẫn được dùng trong việc bảo
28 mật trên môi trường Internet và trao đổi dữ liệu Tác giả cũng kết hợp giải pháp hợp đồng thông minh để ghi lại cam kết giữa các bên khi thực hiện trao đổi
Hình 2.9 Các bước hợp đồng thông minh được thực thi theo mơ hình của Ray
Trong Hình 2.9 dữ liệu được lưu trữ trong đoạn tin FHIR Sau đó các nội dung trong hợp đồng sẽ được thực thi nếu đáp ứng đúng điều kiện đã được biên soạn và đồng thuận.
Phương pháp thực hiện
2.6.1 Trình tự thực hiện một hệ thống thông tin
Tác giả tiến hành thực hiện đề tài theo mô hình phát triển thác nước truyền thống
(do Royce đề xuất vào năm 1970) của một hệ thống thông tin khi được ứng dụng vào thực tế Như vậy trình tự sẽ lần lượt bao gồm các bước trong Hình 2.10:
Bước 1: Xác định bài toàn và đặc tả các yêu cầu
Bước 4: Mã hóa, lập trình
Bước 6: Khai thác và bảo trì
Hình 2.10 Sơ đồ thực hiện một giải pháp hệ thống thông tin theo mô hình thác nước do Royce đề xuất
Tuy nhiên trong phạm vi đề tài, tác giả sẽ không thực hiện bước khai thác và bảo trì do mục tiêu chỉ dừng ở bước thực hiện khả thi hệ thống, chưa tiến tới triển khai thực tế vào quy trình thực tế
2.6.2 Xác định Yêu cầu từ các đơn vị hỗ trợ sinh sản
Tác giả thực hiện lấy yêu cầu từ người dùng cụ thể là các đối tượng: bác sĩ, nữ hộ sinh, chuyên viên phôi học, nhân viên quản lý chất lượng đang làm việc tại các Đơn vị hỗ trợ sinh sản thuộc hệ thống IVFMD
Các yêu cầu cần cho hệ thống thông tin sẽ được tác giả thực hiện qua các phương pháp khơi gợi yêu cầu như: phỏng vấn, thu thập thông tin theo nhóm, đọc tài liệu quy trình và quan sát quy trình thực hiện thực tế Kết quả có được sẽ là các sơ đồ tình trạng hiện trạng, các biểu đồ dòng quy trình theo BPMN, từ đó tiến tới các tài liệu mô tả chi tiết hơn cần để thiết kế hệ thống thông tin Tác giả thực hiện khai thác xoay quanh các nội dung thuộc thành phần của một hệ thống thông tin cơ bản như:
• Các yêu cầu về phần mềm
• Các yêu cầu về phần cứng
• Các yêu cầu về dữ liệu
• Các yêu cầu về con người
2.6.3 Thiết kế và Thực nghiệm hệ thống trên nền tảng Hyberledger fabric
Trong bước này tác tiến hành thực hiện theo tài liệu mô tả hệ thống đã được thiết kế Đầu tiên là tiến hành cài đặt môi trường phát triển ứng dụng phù hợp với nền tảng Các thông tin này được công bố công khai trên trang thông tin của Hyperdeger Fabric
Hình 2.11 Mô tả các thành phần trong hệ thống thực nghiệm
Theo mô tả ở Hình 2.11, sau khi chuẩn bị xong các công cụ để khởi động được hệ thống Tác giả tiến hành thực hiện lập trình hợp đồng thông minh để có thể thiết lập kênh tương tác giữa ứng dụng và sổ cái được tạo trên chuỗi Thêm vào đó, thông qua ứng dụng được hoàn thành trước đó, tác giả thực hiện thử nghiệm các tác vụ đúng theo quy trình thực tế đã tìm hiểu như đưa dữ liệu đầu vào, thực hiện tạo và cập nhật dữ liệu vào sổ cái Cuối cùng, do mục tiêu hướng tới là một mạng chuỗi được cấp quyền nên tác giả cũng tiến hành thử nghiệm thêm một tổ chức mới vào trong chuỗi Để trực quan hóa được các giao dịch được thực thi như thế nào, tác giả tiến hành tích hợp thêm công cụ Hyperledger Explorer để có thể quan sát được cơ chế, số lượng giao dịch phát sinh và các tổ chức đang tham gia vào chuỗi khối
MÔ TẢ HỆ THỐNG ĐỀ XUẤT
Mô tả ngữ cảnh ứng dụng tại Việt Nam
3.1.1 Các tổ chức tham gia vào mạng Để thực hiện quản lý dữ liệu hiến noãn một cách hiệu quả, tác giả đã xác định dùng giải pháp chia sẽ dữ liệu giữa các trung tâm y tế trên nền tảng chuỗi khối giới hạn để tăng cường tính toàn vẹn và an toàn dữ liệu Như vậy, theo mô tả ở Hình 3.1, các trung tâm hỗ trợ sinh sản thuộc hệ thống IVFMD (trải dài từ miền trung vào miền nam) và Vụ sức khỏe bà mẹ và trẻ em (cơ quan trực thuộc Bộ y tế, có chức năng quản lý nhà nước về chăm sóc sức khỏe sinh sản và sức khỏe bà mẹ, trẻ em Các tổ chức này sẽ được khởi tạo và tương tác trong một mạng chuỗi khối được cấp phép, khi một tổ chức mới được thêm hoặc loại ra sẽ do Vụ thực hiện quản lý
Hình 3.1 Mô phỏng hệ thống mạng chuỗi khối quản lý dữ liệu hiến noãn
Còn với mô tả tại một cơ sở y tế cụ thể, tác giả sẽ sử dụng bối cảnh quy trình quản lý dữ liệu hiến noãn tại Đơn vị hỗ trợ sinh sản Mỹ Đức (IVFMD) Trong quy trình này có sự tham gia của nhiều nhân viên y tế như Bác sĩ, Nhân viên y tế kiểm tra pháp lý (Nữ hộ sinh), Chuyên viên phôi học, Người hiến noãn, Người nhận noãn Ngoài các tác nhân là con người thì tại mỗi đơn vị trong hệ thống IVFMD, đều sử dụng các phần mềm hỗ trợ cho quá trình vận hành Tương tác giữa các tác nhân phần mềm cũng đa dạng về nghiệp vụ như quyền đăng nhập vào hệ thống, các hợp đồng thông minh được biên soạn, quy trình mã hóa thông tin giữa các hệ thống
Hình 3.2 Ngữ cảnh tương tác với hệ thống quản lý noãn trên nền tảng chuỗi khối tại một cơ sở y tế
Do có sự tham gia của nhiều đối tượng và vai trò khác nhau, quyền truy cập vào hệ thống sẽ được quy định bởi các chính sách kiểm soát của hệ thống IVFMD Các chính sách này có thể được cụ thể hóa bằng các hợp đồng thông minh, nhờ vậy duy trì được quyền riêng tư và toàn vẹn dữ liệu cho các bên tham gia vào chuỗi khối
Theo mô tả của hình 3.2, các dữ liệu phát sinh xuyên suốt trong quá trình hiến noãn sẽ được liên cục cập nhật vào chuỗi khối Từ bước bệnh nhân đăng ký hiến noãn, sẽ bắt đầu cho tạo một khối mới trong chuỗi Sau khi được tư vấn và tầm soát, nếu đủ điều kiện, các điều khoản trong hợp đồng thông minh sẽ được kích hoạt Đối tượng người hiến noãn sẽ được cập nhật trạng thái ‘khóa’, không thể tham gia điều trị với cặp bệnh nhân khác, và cũng là dấu hiệu cho nhân viên y tế biết để thực hiện quy trình nhận bệnh Các điều khoản khác sẽ tương tự được kích hoạt theo lộ trình hiến noãn, mộ số cột mốc đáng lưu ý như sau: kích hoạt khi số noãn được tạo thành phôi, kích hoạt sau khi chuyển phôi và có kết quả thử thai sau đó
Tác giả cũng hướng đến thiết kế hệ thống giúp cho người dùng có thể thực hiện nhiều tính năng trên hệ thống Ví dụ, bác sĩ có thể kiểm tra tiến trình điều trị của bệnh nhân, lịch sử sử dụng phôi; nhân viên y tế có thể kiểm tra tình trạng noãn hiến được tạo phôi đã được sử dụng như thế nào Nhìn chung toàn bộ các tính năng tạo mới, truy vấn, cập nhật, hủy đều có thể thực hiện tùy theo phân quyền của người dùng trong chuỗi
3.1.2 Cơ chế đạt đồng thuận của hệ thống
Do tính đặc thù hướng tới một mạng trao đổi dữ liệu được thiết kế giới hạn số lượng các tổ chức tham gia vào chuỗi, đồng thời mục đích cũng không thực hiện tiền mã hóa lưu hành trên chuỗi, nên nhà phát hành IBM đang hướng tới ứng
33 dụng các đồng thuận chịu lỗi Fault Tolerance Consenus (FTC) tối ưu được thông lượng giao dịch và chi phí tính toán thấp
Một số đồng thuận được nhà phát hành IBM đã được đề nghị sử dụng dựa trên các tiêu chí đặc thù của hệ thống, ví dụ nếu chỉ triển khai trong nội bộ của một tổ chức thì có thể áp dụng đồng thuận Crash Fault Tolerant (CFT) để thuận tiện cho việc triển khai và chi phí vận hành thấp, ngược lại nếu có nhu cầu giới hạn nhiều tổ chức củng tham gia vào hệ thống thì nên áp dụng thuật toán practical Byzantine Fault Tolerance (pBFT) phù hợp hơn Nhưng nhà phát triển phải chấp nhận thêm nguy cơ bị tấn công từ môi trường bên ngoài do phép truy cập từ nhiều vị trí khác nhau Giải pháp được đề nghị là áp dụng thêm ứng dụng tường lửa để kiểm tra lưu lượng trên nền tảng web từ đó có thể nhận diện các chương trình mã độc có thể gây hại với mô hình mạng ngang hàng
Hình 3.3 Sơ đồ minh họa cách một giao dịch được xác nhận trên hệ thống
Nhưng thực tế, Hyperledger Fabric đang hoạt động khác, không hẳn là một đồng thuận riêng biệt mà có sự tùy chỉnh của riêng nền tảng này được mô tả ở Hình 3.3 Nền tảng triển khai một hệ thống điểm trung gian, còn được gọi là được gọi là Oderer (nó còn được gọi là "nút sắp xếp") thực hiện các giao dịch được chuyển tới Các nút này cùng với các nút đặt hàng khác tạo thành một dịch vụ sắp xếp (Ordering Service) Bởi vì thiết kế của Fabric dựa trên các thuật toán đồng thuận xác định, bất kỳ khối nào được các tác nhân ngang hàng xác thực, đều được đảm bảo là cuối cùng và chính xác Sổ cái không thể phân nhánh, theo cách tương tự như được làm trong nhiều mạng chuỗi khối phân tán và chúng không tồn tại sự khác biệt với nhau Dịch vụ sắp xếp này triển khai với các nút thông qua trình tự ba giai đoạn sau:
• Giai đoạn một: Đề xuất và xác nhận giao dịch
• Giai đoạn hai: Gửi giao dịch và đặt hàng
• Giai đoạn ba: Xác thực và Cam kết Giao dịch
Tóm lại, xuyên sốt ba giai đoạn chứng kiến các khối giao dịch được tạo bởi dịch vụ sắp xếp được các tác nhân nagng hàng áp dụng một cách nhất quán vào sổ cái
Ngoài việc thúc đẩy tính hữu hạn, việc tách biệt xác nhận thực thi chuỗi mã (xảy ra ở các tác nhân ngang hàng - Peer) khỏi việc đặt hàng mang lại cho Fabric lợi thế về hiệu suất và khả năng mở rộng, loại bỏ các tắc nghẽn có thể xảy ra khi thực thi và công việc sắp xếp được thực hiện bởi cùng một nút
Mặc dù mọi dịch vụ sắp xép hiện có đều xử lý các giao dịch và cập nhật cấu hình theo cùng một cách, tuy nhiên vẫn có một số cách triển khai khác nhau để đạt được sự đồng thuận về thứ tự nghiêm ngặt của các giao dịch giữa các nút dịch vụ đặt hàng Trong phạm vi đề tài, tác giả chỉ triển khai theo mô hình Solo của dịch vụ sắp này chỉ dành cho thử nghiệm và chỉ bao gồm một hệ thống sắp xếp duy nhất Thực tế, sơ đồ ở Hình 3.4 này không được dùng nữa và có thể bị xóa hoàn toàn trong các bản phát hành trong tương lai Người dùng Solo hiện tại nên chuyển sang mạng Raft một nút để có chức năng tương đương
Hình 3.4 Sơ đồ mô tả mô hình một hệ thống sắp xếp - Solo
Lựa chọn dịch vụ đặt hàng tiếp theo cho các sản phẩm mạng, nhà phát nền tảng Fabric đã tiếp cận giao thức Raft, và đã thiết lập sử dụng mô hình “người lãnh đạo và người theo dõi”, trong đó người lãnh đạo được bầu cử tự động trong số các nút đặt hàng trong một kênh (tập hợp các nút này được gọi là “tập hợp người đồng ý”) và người lãnh đạo đó sao chép các thông báo tới các nút người theo dõi
Hình 3.5 Sơ mô tả mô hình đa hệ thống sắp xếp triển khai trên Raft
Mô hình ở Hình 3.5 này khác với Solo là triển khai một hệ thống sắp xếp khác nhau thay vì chỉ duy trì một như trước Bởi vì hệ thống có thể duy trì việc mất các nút, bao gồm cả các nút dẫn đầu, miễn là còn lại phần lớn các nút đặt hàng (cái được gọi là “đại biểu”), Raft được cho là Crash Fault Tolerant (CFT) Nói cách khác, nếu có ba nút trong một kênh, nó có thể chịu được việc mất một nút (còn lại hai nút) Nếu bạn có năm nút trong một kênh, bạn có thể mất hai nút (để lại ba nút còn lại) Tính năng này của dịch vụ đặt hàng Raft là một yếu tố giúp thiết lập chiến lược có tính sẵn sàng cao cho dịch vụ đặt hàng của bạn Ngoài ra, trong môi trường sản xuất, bạn sẽ muốn trải rộng các nút này trên khắp các trung tâm dữ liệu và thậm chí cả các vị trí Ví dụ: bằng cách đặt một nút vào ba trung tâm dữ liệu khác nhau Bằng cách đó, nếu một trung tâm dữ liệu hoặc toàn bộ vị trí không khả dụng, các nút trong các trung tâm dữ liệu khác sẽ tiếp tục hoạt động
3.1.3 Quy trình nhân viên y tế kiểm tra thông tin người hiến noãn
Khi một cặp vợ chồng được chỉ định cần xin noãn của người khác để thực hiện thụ tinh trong ống nghiệm, họ sẽ phải tìm một người hiến noãn tự nguyện hiến noãn của mình và vận động người đó đến Đơn vị hỗ trợ sinh sản mình đang điều trị để kiểm tra Theo Hình 3.6, người hiến noãn khi đến phải cung cấp bản chính Căn cước công dân, chứng mình nhân dân để xác đính chính xác thông tin nhân thân của mình Nhân viên y tế (nữ hộ sinh) sẽ mời người hiến vào phòng để kiểm tra và nhập thông tin trên căn cước vào phần mềm để tra trên cơ sơ dữ liệu tại chỗ Lúc này, hệ thống kiểm tra thông tin hành chánh được nhập vào và trả ra kết quả liệu thông tin người hiến noãn đã có trong hệ thống chưa và đủ điều kiện để hiến noãn hay không Trường hợp không đủ điều kiện thì người hiến sẽ không được chấp thuận để hiến và cặp vợ chồng xin noãn sẽ phải vận động một người khác đến Trong trường hợp còn lại, nếu người hiến thỏa mọi điều kiện cho phép, thông tin người hiến sẽ được tạo mới hoặc cập nhật vào cơ sở dữ liệu tại chỗ
Hình 3.6 Quy trình thực hiện kiểm tra tiêu chuẩn người hiến noãn
Nhìn chung các bước kiểm tra thông tin người hiến noãn khá đơn giản, các thao tác được hỗ trợ bởi phần mềm quản lý tại chỗ Điểm hạn chế duy nhất là thao tác kiểm tra thông tin chỉ có thể truy vấn trên duy nhất một cơ sở dữ liệu tại chỗ Các
Mô tả kiến trúc hệ thống chuỗi khối
3.2.1 Tổng quát về kiến trúc hệ thống
Trong phạm vi của đề tài, tác giả cũng tiến hành thử nghiệm trên một hệ thống kết nối để triển khai mô hình ứng dụng phía trên Kiến trúc mạng lưới kết nối được mô tả như Hình 3.12: Thiết kế dựa trên ý tưởng chính là xây dựng một mạng lưới chuỗi khối riêng, chỉ sử dụng cho các chi nhánh dưới sự kiểm soát nội bộ IVFMD Các thành phần trong hệ thống bao gồm các cá nhân như người hiến noãn, cặp vợ chồng tham gia điều trị tham gia vào chuỗi qua các hợp đồng thông minh Các chi nhánh khác sẽ triển khai một mạng phụ, có các thành phần thực hiện kết nối với phía các ứng dụng tương tự như các điểm (node) khác trong hệ thống
Hình 3.12 Mô tả mô hình hệ thống chuỗi khối giữa các cơ sở y tế
Như vậy ta có thể xem toàn bộ hệ thống như ba phần cấu thành nên: Đối tượng tham gia, các ứng dụng và bộ dữ liệu lưu trữ trên chuỗi Đối tượng tham gia thì như đã đề cập là cá nhân trực tiếp tương tác với hệ thống Còn các ứng dụng chịu trách nhiệm giao tiếp với chuỗi thì có độ đa dạng hơn rất nhiều do phụ thuộc nguồn lực công nghệ vào từng ‘điểm’ hay khả năng triển khai ứng dụng tại từng tổ chức Một khi có nhu cầu tương tác với chuỗi, hệ thống cần xác nhận đối tượng gửi yêu cầu truy cập là ai thông qua một mô-đun quản lý tài khoản nhận diện người dùng Bên cạnh đó, hệ thống còn tổ chức mô-đun quản lý các đồng thuận có thể thực thi trên chuỗi, cũng như kiểm soát thứ tự các giao dịch được đề xuất đưa vào chuỗi
Với mô tả Hình 3.13, ta hình dung dễ hơn các thành phần chi tiết có trong một điểm trong chuỗi như: hợp đồng thông minh, dữ liệu các khối, cơ sở dữ liệu giao dịch phát sinh và các quy định thực thi Vai trò của các điểm là chứng thực các giao dịch được đưa vào chuỗi, dữ liệu không chứa các giao dịch chưa được chứng thực hoặc bị sai khác Sổ cái (state database) trong chuỗi dùng để lưu trữ trạng thái của sổ cái tại một thời điểm nhất định Dữ liệu lưu trong cơ sở dữ liệu là các thông tin định danh người hiến noãn như họ tên, mã nhận diện theo căn ước công dân, số phôi còn trữ lạnh và cơ sở y tế đang được đăng ký
Hình 3.13 Minh họa các thành phần của một điểm (node) trong chuỗi khối Đối với sổ cái lưu trữ các khối thì khối đầu tiên được gọi là ‘genesis’, khối này được tạo đầu tiên làm nề tảng cho các khối phía sau phát sinh và ‘liên kết’ Các chuỗi tạo ra sau sẽ tương ứng với các giao dịch theo cấu trúc (Tx1, eggdonor1),
(Tx2, eggdonor2), (Tx3, eggdonor3) và (Txn, eggdonorn) được lưu cặp tương xứng trong cơ sở dữ liệu Thành phần cuối cùng là các quy định hệ thống
(policies) sẽ đóng vai trò xem xét điều kiện để những giao dịch nào được thêm vào chuỗi và thông qua xác thực Các quy định này có thể tùy chỉnh như ‘AND
(‘Dept1.member’, ‘Dept2.member’)’: cần cả hai bộ phận đồng ý giao dịch phát sinh, hoặc ‘OR (‘Dept1.member’, ‘Dept2.member’)’: chỉ cần một trong hai đồng ý là giao dịch đã được xác thực
3.2.2 Mô tả trình tự hoạt động trong chuỗi
Khi hệ thống đã được khởi tạo, và thiết lập các kênh giao tiếp với nhau Ứng dụng từ phía người dùng lúc này có thể đăng ký và nhận được các chứng chỉ truy cập vào hệ thống, tất nhiên các chứng chỉ này luôn tồn tại dưới dạng được mã hóa, điều này giúp an toàn khi bắt đầu xác thực vào hệ thống Ngoài ra, mô-đun quản lý chính sách cũng sẽ được cấu hình theo các giao dịch được phép thực thi trong hệ thống Đi sâu hơn hệ thống Fabrics, quản lý các giao dịch được chia thành các tác nhân và đối tượng xác thực, điều này giúp nâng cao khả năng đồng bộ và tính tức thời cho hệ thống Mội một giao dịch đều được thực hiện vởi một cá nhân và ghi vào sổ cái tại điểm đó Sau đó, nếu giao dịch được chứng thực sẽ được ghi nhận lại với chứng nhận của các tác nhân Thực thi các giao dịch thì lại ưu tiên sắp xếp các giao dịch sao cho có thể xử lý đồng thời nhiều giao dịch tại một thời điểm Đối tượng xác thực không thực thi các giao dịch mà chỉ sắp các giao dịch này và không lưu lại dữ liệu Điểm này giúp các tác nhân trên hệ thống có thể tin cậy giao dịch của mình an toàn và có thể chạy độc lập với các giao dịch khác
Hình 3.14 Mô phỏng trình tự thực thi một giao dịch trên hệ thống
Trong Hình 3.14, chúng ta có thể thấy các bước thực hiện, cũng như vai trò của từng đối tượng trong chuỗi tham gia như thế nào Mô-đun quản lý người dùng nhận diện và cấp mã bảo mật cho ứng dụng từ phía người dùng, sau đó cho phép gửi một giao dịch cần được thông qua vào hệ thống Điểm bắt đầu cho quy trình này là khi ứng dụng phía người dùng thực hiện gửi giao dịch cần thông qua cho các điểm (nodes) còn lại trong hệ thống Các điểm trong hệ thống có thể đóng vai trò là điểm gửi dữ liệu hoặc chỉ đơn giản là xác thực thông qua các giao dịch được gửi lên Nếu chỉ làm vai trò xác thực thì điểm đó sẽ tham gia và ký và thông qua giao dịch được đề nghị gửi tới, trong khi đó, điểm có vai trò cập nhật dữ liệu dựa vào giao dịch đã xác thực để cập nhật lại vào sổ cái của mình Trong hyperledger fabric còn cho phép một điểm đóng vai trò xác thực có thể tham gia vào nhận và thực thi xác nhận giao dịch nhưng không cần phải cập nhật dữ liệu vào sổ cái
Các điểm xác thực thì chỉ thu thập và đọc các tập dữ liệu RW (Read-write) trong khi giao dịch được xác thực Ứng dụng phía người dùng nhận được kết quả xác nhận trả về, tiếp tục đóng gói lại và gửi cho mô-đun quản lý đồng thuận của hệ thống Các đồng thuận được thực thi trong lúc các giao dịch được xử lý trên bộ dũ liệu RW, kết quả sau đó được trả tới các điểm có vai trò cập nhật dữ liệu (commmiter) dưới dạng dữ liệu chuỗi khối Tiếp theo đó, mỗi giao dịch được xác nhận sẽ được đem so sánh giữa tập dữ liệu RW và trạng thái dữ liệu được lưu Bộ dữ liệu được lưu vào sổ cái và tạo một phản hồi về việc thực thi có thành công hay không Các điểm xác nhận dữ liệu cũng sẽ được nhận thông báo trên mỗi sự kiện thực thi thông qua ứng dụng từ phía người dùng
3.2.3 Mô tả các thành phần để khởi tạo
3.2.3.1 Thiết lập nhà cung cấp chứng thực số
Do cơ chế cấp chứng thực số rất quan trọng nên nền tảng Fabric cung cấp sẵn một giải pháp tích hợp để có thể tạo chứng thực số ngay trên nền tảng chuỗi khối đã tạo Giải pháp này được đặt tên là Fabric CA, được đãm nhận vai trò quản lý định danh số trong hệ thống cho các thành phần tham gia trong chuỗi và được cung cấp chứng thực dưới định dạng chứng chỉ X.509, các thành phần trong chứng chỉ được liệt kê chi tiết ở Hình 3.15 Ngoài ra, Fabric CA khởi nguồn để đáp ứng nhu cầu nội bộ của Fabric, nên mặc định không thể được tận dụng để cung cấp chứng thực SSL cho nhu cầu sử dụng với trình duyệt
Hình 3.15 Định dạng chứng thực số cho người dùng khi tham gia vào chuỗi
Tuy vậy, một số chứng thực cần được sử dụng để quản lý định danh, nên Fabric
CA có thể được dùng để cấp và quản lý chứng thực trong một số ít trường hợp Công cụ này cũng phù hợp cho mục đích sủ dụng thương mại hoặc làm nhà cung cấp chứng thực số cấp trung cấp
Trong phạm vi thực nghiệm hệ thống, tác tiến hành khai báo đăng ký định danh theo phương thức đơn giản thông qua Fabric CA Các thông tin tương đối đơn giản như là tên người dùng và tổ chức của họ là gì, ngoài ra cần thêm các thông tin mô tả như bộ phận hoạt động, vai trì hoặc có thể cần khai báo mã định danh của người đó Khi nói vè định danh, chúng ta sẽ phải đề cập hết các thuộc tính cần xác định để cấp quyền Trong nền tảng Hyperledger Fabric, được mô tả định danh theo cấu trúc “MSP.ROLE”, trong đó MSP chứa thông tin mã định danh của nhân viên đó trực thuộc, còn “ROLE” đại diện cho một trong các vị trí sau:
Member, Admin, Client và Peer Mỗi một vai trò được định danh gắn liền với một thông tin người dùng được đăng ký với cơ quan chứng thực số
Trong môi trường thực nghiệm các vai trò được tạo ra trong bảng sau:
• ‘OrdererOrg.Orderer’: vai trò sắp xếp của OrdererOrg MSP
• ‘Org1.Admin: quản trị viên của Org1 MSP
• ‘Org1.Peer’: tác nhân ngang hàng của Org1 MSP
• ‘Org2.Admin: quản trị viên của Org2 MSP
• ‘Org2.Peer’: tác nhân ngang hàng của Org2 MSP
3.2.3.2 Thiết lập các quy định thực thi
Mọi hệ thống đều đầu bắt đầu với kênh hệ thống đầu tiên Đối với một mạng chuỗi khối Hyperledger bắt buộc phải có dịch vụ sắp xếp trước (ordering service), và đây cũng là kênh được tạo ra đầu tiên Kênh hệ thống được thành lập cũng xác định xem những tổ chức nào tham gia vào vai trò thành viên trong dịch vụ sắp xếp giao dịch phát sinh Như vậy, đối với bước thiết lập hệ thống đề xuất ban đầu, tác giả thực hiện cấu hình mặc định như sau:
• Đối với “Org1– Policies” (Org2 tương tự):
Rule: "OR('Org1MSP.admin', 'Org1MSP.peer', 'Org1MSP.client')" Writers:
Rule: "OR('Org1MSP.admin', 'Org1MSP.client')"
Rule: "OR('Org1MSP.admin')"
Rule: "OR('Org1MSP.peer')"” Ở tầng cấu hình ứng dụng của kênh, nếu sử dụng chính sách bao hàm để cấu hình ở phạm vi toàn tổ chức thì có thể dùng các định nghĩa như “ANY” để chỉ cần một những tổ chức đó thông qua, hoặc “ALL” là cần tất cả, hoặc dùng định nghĩa
“MAJORITY” Cách định nghĩa này được đánh giá thân thiện và dễ dùng, bản thân mỗi tổ chức có thể tự định nghĩa để tiến hành cấu hình ở cấp tổ chức Đối với các chính sách áp dụng trong phạm vi ứng dụng của channel, tác giả chuyển sang cấu hình theo mô thức xét duyệt tuần tự các cấp thay cho mô thức ký xác nhận như ở cấp hệ thống:
HIỆN THỰC MÔ HÌNH ĐỀ XUẤT
Khởi tạo hệ thống chuỗi khối
4.1.1 Thiết lập môi trường hệ thống
Môi trường phát triển thực nghiệm cho đề tài này được chia thành hai phần Hệ thống hạ tầng và ứng dụng được chia thành hai môi trường khác biệt nhau Đối với môi trường hạ tầng kỹ thuật để phát triển hệ thống quản lý dữ liệu hiến noãn được triển khai trên môi trường ảo hóa Docker, các thông tin chi tiết được liệt kê ở bảng Ở Bảng 4.1, tác giả thực hiện mô tả thành phần hệ thống, trong đó toàn bộ phần cứng triển khai được thực hiện trên hệ điều hành mã nguồn mở Linux CentOS với cấu hình phần cứng gồm chip Intel Core i5-8500 @ 3.00GHz và bộ nhớ RAM 8 GB Phiên bản áo hóa của phần mềm Docker được dùng là Desktop Engien v20.10.21 và lớp ảo hóa dùng phiên bản Docker Desktop phiên bản 4.14.1 Tác giả cũng sử dụng nền tảng Hyperledger Fabric (v.2.2.11.) được duy trì bởi tổ chức Linux Foundation Các phiên bản sử dụng để xây dựng hợp đồng thông minh thì tác giả sử dụng ngôn ngữ Javascript và Node (v.14.1) để duy trì hệ thống mạng
Bảng 4.1 Các thành phần của hạ tầng phát triển hệ thống
Các thành phần Mô tả
Các công cụ và công nghệ được tác giả sử dụng để triển khai giao diện người dùng bao gồm ở bảng Đây là một giao diện ứng dụng web phát triển trên nền tảng và thư viện Vuejs và Ant design, ngôn ngữ lập trình vẫn sử dụng Javascript như hệ thống ở hạ tầng Nền tảng ứng dụng này đều có thể chạy bằng các trình duyệt phổ biến như Google Chrome, Microsoft Edge và Firefox Đối với mạng dựng API server, nơi kết nối giữa hạ tầng và ứng dụng, thì sử dụng các cấu hình bởi một ngôn ngữ gần đây là Typescript của Google, và duy trì bởi máy chủ Nginx, xem chi tiết ở Bảng 4.2 Các ứng dụng có thể kết nối thông qua
51 hạ tầng này này để thực thi truy vấn và trên một giao diện thân thiện để kết nối với hệ thống Từ phía người dùng các thể thao tác thực hiện các giao thức HTTP như POST, GET, PUT, and DELETE gửi tới máy chủ API kèm theo đó mã JobID Hệ thống chuỗi khối sẽ thực thi yêu cầu mà gửi về kết quả theo đúng mã JobID và cũng bằng giao thức HTTP
Bảng 4.2 Các thành phần của ứng dụng phía người dùng
Các thành phần Mô tả
Ngôn ngữ lập trình Javascript, SCSS
Thư viện Vuejs & Ant Design
Browser Google Chrome, Microsoft Edge và Firefox
4.1.2 Khởi tạo các thành phần của hệ thống
Thực hiện khởi tạo hệ thống, theo đó là kênh trao đổi của các tổ chức bằng công cụ Docker với cú pháp kết hợp: /network.sh up createChannel -ca Trong đó, -ca đóng vai trò ra lệnh khởi tạo kèm nhà cung cấp chứng thực số tạo bởi Fabric CA Kết quả thực thi tạo hệ thống, kết quả trả về trên của sổ thực thi lệnh:
Creating network "fabric_test" with the default driver
Creating volume "net_orderer.example.com" with default driver
Creating volume "net_peer0.org1.example.com" with default driver
Creating volume "net_peer0.org2.example.com" with default driver
Creating peer0.org2.example.com done
Creating orderer.example.com done
Creating peer0.org1.example.com done
Anchor peer set for org 'Org1MSP' on channel 'mychannel'
Anchor peer set for org 'Org2MSP' on channel 'mychannel'
Sau khi hệ thống hạ tầng được khởi tạo thành công, ta sẽ có các thành phần như hai tổ chức Org1, Org2, Oderer và kênh giao tiếp tên ‘mychannel’ Tiếp tục đưa hợp đồng thông minh lên kênh, mã chuỗi sẽ được đóng gói và gửi đến xác nhận vởi các tổ chức Lúc này hệ thống sẽ lần lượt yêu cầu đồng thuận vởi tổ chức Org1 và Org2 Sau khi được chấp nhận sẽ chính thức thực thi trên kênh vừa tạo Kết quả thực thi trả về khi thực hiện tuần tự sẽ là:
+ peer lifecycle chaincode package basic.tar.gz path /asset-transfer- basic/chaincode-javascript/ lang node label basic_1.0
Chaincode is installed on peer0.org1
Chaincode definition approved on peer0.org1 on channel 'mychannel' Chaincode is installed on peer0.org2
Chaincode definition approved on peer0.org2 on channel 'mychannel' Chaincode definition committed on channel 'mychannel'
Kết quả hiện thực trên ứng dụng
4.2.1 Thao tác với ứng dụng
Theo quy trình, người dùng sẽ nhận thông tin của người hiến noãn là bản chính của Căn cước công dân Sau đó sẽ đăng nhập vào phần mềm quản lý theo tài khoản cá nhân của mình Khi đăng nhập sẽ đồn thời gửi đến hệ thống chuỗi khối một thông tin yêu cầu kết nối vào Tùy theo phân vai trò của mình mà hệ thống cho phép thực thi các tác vụ khác nhau Tác vụ đơn giản nhất là xem thông tin của người hiến có tồn tại trong hệ thống hay không Kết quả trả ra như hình 4.1
Hình 4.1 Kết quả xem chi tiết thông tin người hiến noãn theo mã căn cước
Khi người dùng thực hiện thao tác gửi tìm kiếm, uứng dụng sẽ gưởi đế máy chủ API một lệnh và được ghi nhận trong hàng chờ với mã thực thi thành công 202 Sau khi có kết quả sẽ trả về kết quả từ hệ thống chuỗi khối với mã 200 như hình 4.2
Hình 4.2 Kết quả thực thi tới máy chủ API
Thêm một ví dụ khác, nếu người dùng sau khi tìm kiếm không thấy thông tin người hiến noãn, sẽ phải tọa mới và đưa vào hệ thống để quán lý Lúc này trường cho phép cho noãn sẽ phải nhập mã 1, tương ứng với đang sẵn sàng để hiến noãn với không có phôi trữ tạo từ noãn hiến Chi tiết các thông tin tạo mới xem ở Hình 4.3
Hình 4.3 Giao diện tạo mới người hiến noãn
Kết quả thực thi sau khi đồng thuận được chấp nhận trên chuỗi, dữ liệu người hiến sẽ được thêm vào trong sổ cái Lúc này, phải thực hiện lại một lệnh xem kết quả được lưu trên cơ sở dữ liệu tình trạng của chuỗi – world state Người hiến noãn Nguyễn Thị C sẽ được liệt kê trong danh sách người hiến như mô tả trong Hình 4.4
Hình 4.4 Kết quả tạo mới Nguyên Thi C vào hệ thống thành công
4.2.2 Trực quan hóa dữ liệu trên chuỗi bằng Hyperledger Explorer Để trực quan hóa các dữ liệu chạy ở hạ tầng chuỗi khối, IBM còn cung cấp công cụ Hyperledger Explorer để giúp người quản trị dễ hình dung hơn các kết quả đang thực thi trên chuỗi Công cụ này cần thông tin mã hóa, xác thực từ một cấp quản trị viên trong hệ thống Tác giả thực hiện cung cấp chứng chỉ và khóa bí mật của quản trị viên của tổ chức Org1 để công cụ này có thể đọc dữ liệu từ điểm của mình Như Hình 4.5, mạng được dựng thành công với bảy khối đã được tạo, tương ứng với bảy giao dịch xác thực thành công và hiện nay đang duy trì hai tổ chức tham gia vào chuỗi (không tính Oderer) kèm theo đó làm 1 hợp đồng thông minh được thực thi trên kênh ‘mychannel’
Hình 4.5 Bảng thông tin các thành phần trên hệ thống
Các khối giao dịch được chứng mình là minh bạch và an toàn với các mã chuỗi khối lưu trên từng khối cúa mã hóa của khối trước Khi cố tình thay đổi ở một khối thì các khối sau sẽ bị sai mã hóa này Minh họa chi tiết xem thêm ở Hình 4.6
Hình 4.6 Minh họa các khối lưu các mã hash lẫn nhau, đảm báo tính không thể sửa đổi trên sổ cái
4.2.3 Thêm một tổ chức mới vào kênh đang có
Trong thực tế, có khả năng cần đổ mở rộng các tổ chức tham gia vào trong hệ thống nên việc thêm các tổ chức khác cũng cần được chuẩn bị Nền tảng Hyperledger Fabric cũng hỗ trợ việc thêm mới các điểm vào hệ thống, tuy nhiên do là mạng giới hạn quyền truy cập nên các tổ chức này cũng cần phải được định danh, cung cấp các chứng thực số để nhận diện trên hệ thống Như vậy, trình tự sẽ thực hiện khai báo và gửi đăng ký đến Fabric CA, sau đó gửi lại các chứng thực cho Org3, kết quả thực hình thành công được mô phỏng qua Hình 4.7
Hình 4.7 Sau khi thêm thành công, bảng thông tin sẽ tính số 'node' là 3 Điểm cần lưu ý là khi thêm vào cũng cần tuân theo quy định của cấp kênh giao tiếp khi khởi tạo kênh lúc ban đầu, do cấu hình “ALL Org” nên để đưa Org3 vào thành công cần xác thực đủ của cả Org1, Org2 Các lệnh được thực thi như sau:
Generating certificates using cryptogen tool
Generating CCP files for Org3
Generating and submitting config tx to add Org3
Creating config transaction to add org3 to network
Config transaction to add org3 to network submitted
Anchor peer set for org 'Org3MSP' on channel 'mychannel' Channel 'mychannel' joined
Org3 peer successfully added to network