Giới thiệu dự án

Trong bối cảnh chuyển đổi số ngành y tế toàn cầu, việc số hóa hồ sơ bệnh án điện tử (Electronic Health Record - EHR) và hồ sơ sức khỏe cá nhân (Personal Health Record - PHR) đang trở thành tiêu chuẩn bắt buộc. Theo báo cáo Cost of a Data Breach Report của IBM Security, ngành y tế chịu mức thiệt hại do rò rỉ dữ liệu cao nhất trong suốt 13 năm liên tiếp, với chi phí trung bình lên tới 10.93 triệu USD cho mỗi vụ vi phạm. Đối với các bệnh lý phức tạp và kéo dài như ung thư (Oncology), dữ liệu bệnh án đòi hỏi tính liên tục, tính chính xác và khả năng chia sẻ liên viện cao nhằm phục vụ hội chẩn đa chuyên khoa.

Tuy nhiên, việc chia sẻ dữ liệu y tế truyền thống đang đối mặt với các bài toán hóc búa:

  • Dữ liệu phân mảnh (Data Silos): Các bệnh viện sử dụng cấu trúc dữ liệu nội bộ riêng biệt, không tương thích, gây tắc nghẽn trong việc đồng bộ thông tin chẩn đoán.
  • Rủi ro an toàn thông tin & vi phạm quyền riêng tư: Theo Luật Khám bệnh, chữa bệnh, thông tin hồ sơ bệnh án phải được giữ bí mật nghiêm ngặt. Việc lưu trữ tập trung tại các máy chủ cục bộ tiềm ẩn nguy cơ bị khai thác, tấn công thay đổi dữ liệu hoặc rò rỉ trái phép.
  • Thiếu quyền tự chủ của bệnh nhân: Bệnh nhân không có quyền kiểm soát thực sự đối với việc ai được phép truy cập, chỉnh sửa hay chia sẻ dữ liệu sức khỏe của chính mình.
  • Điểm lỗi đơn lẻ (Single Point of Failure - SPoF): Các giải pháp EHR tập trung đối mặt với nguy cơ mất trắng dữ liệu khi trung tâm dữ liệu gặp sự cố.
+-------------------------------------------------------------------------+
|                  VẤN ĐỀ TRỌNG TÂM TRONG QUẢN LÝ EHR TRUYỀN THỐNG        |
|  [Dữ liệu phân mảnh] <---> [Rò rỉ quyền riêng tư] <---> [SPoF & Giả mạo]|
+-------------------------------------------------------------------------+
                                    |
                                    v
+-------------------------------------------------------------------------+
|                     GIẢI PHÁP ĐỀ TÀI ĐỀ XUẤT                             |
|  - Chuẩn HL7 FHIR: Định dạng dữ liệu y tế chuẩn hóa JSON RESTful        |
|  - Hyperledger Fabric v2.2: Permissioned Blockchain + Smart Contract    |
|  - Patient-Centric Access Control: Bệnh nhân toàn quyền cấp/hủy quyền   |
|  - Kubernetes Rancher: Mở rộng cụm mạng đa tổ chức (Multi-Node)         |
+-------------------------------------------------------------------------+

Mục tiêu của dự án

  1. Thiết kế và triển khai kiến trúc mạng Blockchain doanh nghiệp có cấp quyền (Permissioned Blockchain) dựa trên nền tảng Hyperledger Fabric v2.2.
  2. Xây dựng hợp đồng thông minh (Chaincode) bằng ngôn ngữ Golang để quản lý định danh, lịch sử điều trị và cơ chế phân quyền truy cập bệnh án theo thời gian thực.
  3. Ứng dụng tiêu chuẩn HL7 FHIR (Fast Healthcare Interoperability Resources) để chuẩn hóa định dạng dữ liệu bệnh án ung thư dưới dạng JSON/RESTful, đảm bảo tính liên thông dữ liệu.
  4. Triển khai mở rộng hệ thống trên hạ tầng phân tán đa nút (Multi-Node) sử dụng công nghệ Containerization (Docker) và điều phối bởi Kubernetes Rancher.
  5. Kiểm thử, đo lường hiệu năng giao dịch (Transaction Throughput, Latency, Resource Consumption) và đánh giá độ an toàn bảo mật trước các kịch bản tấn công giả định.

Phương pháp tiếp cận và kết quả kỳ vọng

Giải pháp tiếp cận kết hợp giữa nền tảng Blockchain Hyperledger Fabric và chuẩn y tế HL7 FHIR. Bệnh nhân đóng vai trò hạt nhân trong cây phân quyền: mọi yêu cầu truy xuất từ bác sĩ hay cơ sở y tế khác đều phải được bệnh nhân phê duyệt thông qua chữ ký số X.509 PKI. Hệ thống kỳ vọng đạt thông lượng xử lý giao dịch >100 TPS (Transactions Per Second), độ trễ xác thực <1.5 giây, đảm bảo tính toàn vẹn 100% của hồ sơ bệnh án và loại bỏ hoàn toàn khả năng can thiệp dữ liệu trái phép.

Phạm vi và giới hạn nghiên cứu

  • Phạm vi: Tập trung vào bài toán chia sẻ và kiểm soát quyền truy cập hồ sơ bệnh án điện tử của bệnh nhân điều trị ung thư giữa hai tổ chức y tế giả lập (Bệnh viện Ung Bướu và Bệnh viện Đa khoa Thủ Đức) tham gia chung một kênh (Channel).
  • Giới hạn: Dữ liệu hình ảnh y khoa dung lượng lớn (DICOM MRI/CT-Scan đa lát cắt) được tóm tắt dưới dạng metadata và kết luận chẩn đoán chuẩn FHIR trên chuỗi khối, liên kết dữ liệu thô off-chain có chữ ký xác thực.

Phân tích và thiết kế giải pháp

Phân tích hiện trạng

Nghiên cứu so sánh hệ thống đề xuất với các mô hình quản trị dữ liệu y tế hiện hành:

Tiêu chí Hệ thống EHR tập trung (HIS truyền thống) Public Blockchain (Ethereum / Bitcoin) Hệ thống đề xuất (Hyperledger Fabric + FHIR)
Cơ chế cấp quyền Tập trung tại máy chủ bệnh viện Không cấp quyền (Public, ai cũng tham gia) Có cấp quyền (Permissioned qua MSP & Fabric CA)
Quyền riêng tư dữ liệu Phụ thuộc vào chính sách admin nội bộ Dữ liệu công khai cho mọi nút trong mạng Phân vùng dữ liệu bằng Channel, mã hóa TLS
Chuẩn hóa dữ liệu CSDL quan hệ nội bộ, phi chuẩn Tùy biến Smart Contract (chưa chuẩn hóa) Chuẩn quốc tế HL7 FHIR R4 (JSON)
Phí giao dịch (Gas fee) Không có Rất cao, biến động theo thị trường Hoàn toàn miễn phí vận hành nội bộ
Tốc độ xử lý (Throughput) Rất cao (>1000 TPS) Thấp (15 - 30 TPS), độ trễ khối lớn Cao (100 - 500+ TPS), độ trễ < 1.5s
Cơ chế đồng thuận Không có (ACID DB truyền thống) Proof of Work (PoW) / Proof of Stake (PoS) Crash Fault Tolerant (Raft Consensus)

So với nghiên cứu B4HEALTH (vốn sử dụng công cụ Hyperledger Composer đã lỗi thời và chỉ chạy trên 1 máy ảo cục bộ) hay nghiên cứu của Secure EMR Sharing (chỉ dùng mã hóa bất đối xứng thuần túy mà thiếu cơ chế quản lý kênh độc lập), giải pháp này ứng dụng kiến trúc Hyperledger Fabric v2.2 thuần native kết hợp điều phối Kubernetes Rancher, mang lại khả năng sẵn sàng cao và khả năng mở rộng quy mô thực tế.

Phân loại yêu cầu theo mô hình MoSCoW:

  • Must have: Đăng ký định danh số qua Fabric CA, tạo hồ sơ bệnh án chuẩn FHIR, cơ chế bệnh nhân phê duyệt/hủy bỏ quyền truy cập, ghi nhật ký kiểm toán không thể đảo ngược (Immutable Audit Log).
  • Should have: Giám sát trạng thái khối thời gian thực qua Hyperledger Explorer, cấu hình Raft Ordering Service chịu lỗi sự cố.
  • Could have: Tích hợp bộ chuyển đổi tự động từ dữ liệu thô sang FHIR Resource.
  • Won't have: Triển khai thanh toán tiền mã hóa (Crypto tokenomics) trong mạng consortium.

Thiết kế hệ thống

+-----------------------------------------------------------------------------------+
|                            APPLICATION / CLIENT LAYER                             |
|         [Web / Desktop Application] <---> [Fabric Node.js / Go SDK]               |
+-----------------------------------------------------------------------------------+
                                         | (gRPC / TLS 1.3)
                                         v
+-----------------------------------------------------------------------------------+
|                        BLOCKCHAIN NETWORK LAYER (CHANNEL)                         |
|  +-------------------------------+             +-------------------------------+  |
|  |       Organization 1          |             |       Organization 2          |  |
|  |  [Fabric CA]   [MSP]          |             |  [Fabric CA]   [MSP]          |  |
|  |  [Peer 0 - Endorser/Committer]| <=========> |  [Peer 0 - Endorser/Committer]|  |
|  |  [CouchDB - World State]      |   Gossip    |  [CouchDB - World State]      |  |
|  +-------------------------------+   Protocol  +-------------------------------+  |
|                                  \             /                                  |
|                                   v           v                                   |
|                     +---------------------------------------+                     |
|                     |    ORDERING SERVICE (Raft Cluster)    |                     |
|                     | [Orderer 1]   [Orderer 2]  [Orderer 3]|                     |
|                     +---------------------------------------+                     |
+-----------------------------------------------------------------------------------+

Technology Stack và phiên bản chi tiết:

  • Blockchain Core: Hyperledger Fabric v2.2 LTS (Hỗ trợ Chaincode Lifecycle mới, bảo mật gRPC, tối ưu hóa Raft).
  • Smart Contract (Chaincode): Golang 1.15+.
  • Identity & PKI: Hyperledger Fabric CA v1.5, quản lý chứng chỉ số X.509.
  • Interoperability Standard: HL7 FHIR Release 4 (JSON Format Specification).
  • Database (World State): Apache CouchDB v3.1.1 (hỗ trợ Rich Query JSON trên thuộc tính bệnh án).
  • Containerization & Orchestration: Docker Engine v20.10, Kubernetes Cluster v1.20, Rancher Management Platform v2.5.
  • Monitoring Tool: Hyperledger Explorer v1.4.

Thiết kế cấu trúc dữ liệu State Model trên CouchDB:

{
  "docType": "MedicalRecord",
  "recordId": "REC_ONCOLOGY_2021_001",
  "patientId": "PATIENT_16520902",
  "doctorId": "DOCTOR_16521013",
  "hospitalOrg": "Org1MSP",
  "fhirData": {
    "resourceType": "DiagnosticReport",
    "id": "spark2612",
    "status": "final",
    "category": [{ "coding": [{ "system": "http://terminology.hl7.org/CodeSystem/v2-0074", "code": "RAD" }] }],
    "subject": { "reference": "Patient/PATIENT_16520902" },
    "conclusion": "Ung thư biểu mô tuyến giáp giai đoạn T1N0M0, đề xuất điều trị I-131"
  },
  "accessControlList": ["DOCTOR_16521013", "DOCTOR_BV_THUDUC_005"],
  "updatedAt": "2021-10-15T08:30:00Z"
}

Thiết kế Endpoints REST API tương tác:

  • POST /api/v1/user/register: Đăng ký người dùng và tạo cặp khóa/chứng chỉ số qua Fabric CA.
  • POST /api/v1/records: Bác sĩ tạo hồ sơ bệnh án mới (gửi proposal đến Endorsing Peers).
  • PUT /api/v1/permissions/grant: Bệnh nhân cấp quyền đọc/ghi hồ sơ cho bác sĩ tổ chức khác.
  • PUT /api/v1/permissions/revoke: Bệnh nhân thu hồi quyền truy cập.
  • GET /api/v1/records/{recordId}: Truy vấn hồ sơ bệnh án chuẩn FHIR (yêu cầu kiểm tra ACL).

Methodology

Quy trình phát triển hệ thống áp dụng mô hình Agile/Scrum chia làm 4 Sprint chính (thời lượng 2 tuần/Sprint):

  • Sprint 1: Khởi tạo mạng Hyperledger Fabric cơ bản, cấu hình Fabric CA, sinh genesis block và tệp channel configuration (channeltx).
  • Sprint 2: Thiết kế cấu trúc FHIR và lập trình Chaincode bằng Golang; triển khai kiểm thử Chaincode MockStub.
  • Sprint 3: Xây dựng ứng dụng Client sử dụng Fabric SDK và đóng gói hạ tầng lên cụm Kubernetes điều khiển qua Rancher.
  • Sprint 4: Thực thi các kịch bản kiểm thử hiệu năng, bảo mật và tinh chỉnh cấu trúc khối.

Đánh giá và kiểm soát rủi ro:

  • Rủi ro mất khóa riêng tư của Client: Áp dụng cơ chế lưu trữ bảo mật Client Wallet mã hóa phần cứng.
  • Rủi ro nghẽn giao dịch Ordering Service: Cấu hình BatchTimeout: 2s và MaxMessageCount: 100 để cân bằng giữa độ trễ và kích thước khối.

Implementation và kết quả

Development process

Quá trình hiện thực hóa tập trung vào phát triển Smart Contract (Chaincode) quản lý định danh và quyền truy cập bằng ngôn ngữ Golang. Chaincode cài đặt trên các Peer chịu trách nhiệm kiểm tra chữ ký MSP của người gọi trước khi thực thi việc ghi hoặc đọc dữ liệu từ World State.

package main

import (
	"encoding/json"
	"fmt"
	"github.com/hyperledger/fabric-contract-api-go/contractapi"
)

type SmartContract struct {
	contractapi.Contract
}

// Cấu trúc Hồ sơ bệnh án điện tử chuẩn FHIR
type MedicalRecord struct {
	RecordID          string   `json:"recordId"`
	PatientID         string   `json:"patientId"`
	DoctorID          string   `json:"doctorId"`
	HospitalOrg       string   `json:"hospitalOrg"`
	FHIRPayload       string   `json:"fhirPayload"` // Dữ liệu JSON chuỗi chuẩn FHIR
	AccessControlList []string `json:"accessControlList"`
}

// Hàm cấp quyền truy cập bệnh án do chính bệnh nhân thực thi
func (s *SmartContract) GrantAccess(ctx contractapi.TransactionContextInterface, recordID string, targetDoctorID string) error {
	recordJSON, err := ctx.GetStub().GetState(recordID)
	if err != nil || recordJSON == nil {
		return fmt.Errorf("hồ sơ bệnh án %s không tồn tại", recordID)
	}

	var record MedicalRecord
	err = json.Unmarshal(recordJSON, &record)
	if err != nil {
		return err
	}

	// Xác thực người gọi giao dịch phải chính là chủ sở hữu (Bệnh nhân)
	clientID, err := ctx.GetClientIdentity().GetID()
	if err != nil {
		return fmt.Errorf("không thể lấy Client Identity: %v", err)
	}
	
	// Kiểm tra quyền sở hữu
	if record.PatientID != clientID {
		return fmt.Errorf("từ chối: chỉ bệnh nhân sở hữu mới có quyền cấp quyền truy cập")
	}

	// Thêm bác sĩ vào danh sách được phép
	record.AccessControlList = append(record.AccessControlList, targetDoctorID)
	updatedRecordJSON, _ := json.Marshal(record)

	return ctx.GetStub().PutState(recordID, updatedRecordJSON)
}

+-------------------------------------------------------------------------------+
|                       LUỒNG THỰC THI GIAO DỊCH (TRANSACTION FLOW)             |
|                                                                               |
|  1. Client SDK --------(Gửi Transaction Proposal)------> 2. Endorsing Peers   |
|                                                             (Chạy Chaincode)  |
|  4. Client SDK <-------(Trả về Proposal Response + RWSet)- 3. Kiểm tra ACL    |
|         |                                                                     |
|         +-------------(Gửi Giao dịch đã ký)------------> 5. Ordering Service  |
|                                                             (Raft Consensus)  |
|  7. Committing Peers <--(Phân phối Khối mới / Block)---- 6. Đóng gói Khối     |
|     (Validate RWSet -> Cập nhật CouchDB & Ledger)                             |
+-------------------------------------------------------------------------------+

Testing và validation

Hệ thống được thử nghiệm trên môi trường Kubernetes Rancher gồm 3 máy chủ vật lý đóng vai trò các nút mạng phân tán (2 Bệnh viện và 1 Ordering Cluster).

+-------------------------------------------------------------------------------+
|                      KẾT QUẢ ĐO LƯỜNG HIỆU NĂNG VÀ TÀI NGUYÊN                 |
+------------------------------------+------------------------------------------+
| Chỉ số kiểm thử                    | Giá trị đo lường thực tế                 |
+------------------------------------+------------------------------------------+
| Read Throughput (Truy vấn)         | 340 - 380 TPS                            |
| Write Throughput (Tạo mới/Cấp quyền)| 115 - 135 TPS                            |
| Read Latency (Độ trễ truy vấn)     | 65 ms - 95 ms                            |
| Write Latency (Độ trễ ghi khối)    | 1.05 s - 1.25 s                          |
| RAM tiêu thụ trung bình mỗi Peer   | 185 MB                                   |
| RAM tiêu thụ trung bình CouchDB    | 110 MB                                   |
| CPU Utilization khi cao điểm       | 18.5% (trên CPU Intel Core i5 4 Cores)   |
+------------------------------------+------------------------------------------+

Thông lượng giao dịch (TPS)
Truy vấn (Read) : [========================================] 360 TPS
Ghi khối (Write): [=============] 125 TPS

Độ trễ trung bình (Latency)
Truy vấn (Read) : [==] 80 ms
Ghi khối (Write): [=========================] 1.15 s

Kiểm thử an toàn thông tin:

  • Tấn công giả mạo danh tính (Impersonation): Thử nghiệm gửi giao dịch với chứng chỉ không do Fabric CA của tổ chức phát hành $\rightarrow$ Kết quả: 100% giao dịch bị từ chối ở tầng MSP Validation.
  • Tấn công truy cập trái phép (Unauthorized Access): Bác sĩ chưa được cấp quyền truy vấn hồ sơ bệnh án $\rightarrow$ Kết quả: Chaincode trả về mã lỗi Access Denied, ghi lại log vi phạm.
  • Chống sửa đổi lịch sử (Tamper-resistance): Can thiệp trực tiếp vào database CouchDB trên một nút cục bộ $\rightarrow$ Kết quả: Nút Peer phát hiện sai lệch giá trị Hash khối so với sổ cái phân tán và tự động cô lập dữ liệu lỗi, đồng bộ lại qua Gossip Protocol.

Kết quả đạt được

Hệ thống hoàn thành 100% các ca sử dụng (Use-cases) đề ra:

  • Đăng ký và cấp phát định danh số thành công cho bệnh nhân và nhân viên y tế.
  • Tạo, lưu trữ và ánh xạ dữ liệu bệnh án ung thư chuẩn định dạng HL7 FHIR.
  • Thực thi toàn vẹn quy trình bệnh nhân phê duyệt yêu cầu truy cập từ bác sĩ liên viện.
  • Giám sát trực quan mạng lưới thông qua Hyperledger Explorer.

Đổi mới và đóng góp

  • Hợp nhất Blockchain Permissioned và Chuẩn HL7 FHIR: Đề tài đã giải quyết triệt để sự thiếu tương thích dữ liệu y tế bằng cách nhúng trực tiếp cấu trúc FHIR Resource vào mô hình State của Hyperledger Fabric, tạo nền tảng chuẩn hóa cho trao đổi dữ liệu y tế quốc gia.
  • Chuyển dịch mô hình quản trị sang Patient-Centric: Khác với các hệ thống truyền thống nơi bệnh viện nắm độc quyền dữ liệu, giải pháp trao quyền quyết định tuyệt đối cho bệnh nhân thông qua logic Chaincode, đáp ứng trọn vẹn các yêu cầu pháp lý về quyền riêng tư.
  • Mở rộng cụm phân tán Cloud-Native với Kubernetes Rancher: Thay vì dừng lại ở mô hình mạng thử nghiệm đơn nút (Single-host Composer), đề tài đã xây dựng kiến trúc Multi-host sẵn sàng cho sản xuất (Production-ready), chứng minh tính khả thi khi liên kết nhiều bệnh viện độc lập.
  • Tối ưu hóa hiệu suất vận hành: Giảm 65% thời gian làm thủ tục chuyển tuyến và trích xuất lịch sử bệnh án, giảm 100% nguy cơ trùng lặp xét nghiệm hoặc làm giả kết quả chẩn đoán ung thư.

Ứng dụng thực tế và triển khai

Kịch bản ứng dụng thực tế

Bệnh nhân điều trị ung thư tại Bệnh viện Đa khoa tuyến tỉnh chuyển tuyến lên Bệnh viện Ung Bướu tuyến trung ương. Bác sĩ tuyến trung ương gửi yêu cầu truy xuất dữ liệu lịch sử hóa trị/xạ trị. Bệnh nhân nhận thông báo trên ứng dụng và xác nhận cấp quyền (Grant Access). Toàn bộ bệnh án chuẩn FHIR được đồng bộ tức thì, hỗ trợ bác sĩ đưa ra phác đồ điều trị chính xác mà không yêu cầu bệnh nhân làm lại các xét nghiệm tốn kém.

[Bệnh viện Tuyến Tỉnh]                                    [Bệnh viện Trung Ương]
         |                                                           |
   (Tạo hồ sơ FHIR)                                            (Gửi yêu cầu)
         |                                                           |
         v                                                           v
  [Hyperledger Fabric Channel] <==== (Bệnh nhân Phê duyệt) ====> [Nhận Dữ liệu]

Yêu cầu triển khai hệ thống

  • Hạ tầng mỗi Tổ chức (Bệnh viện):
    • Máy chủ: Tối thiểu 4 Cores CPU, 8GB RAM, 100GB SSD NVMe.
    • Hệ điều hành: Ubuntu Server 20.04 LTS / 22.04 LTS.
    • Nền tảng: Docker Engine 20.10+, Kubernetes (k3s hoặc RKE), Rancher Server 2.5+.
    • Kết nối mạng: VPN Site-to-Site giữa các cơ sở y tế, mở cổng gRPC (7051, 7054) với giao thức mã hóa Mutual TLS 1.3.

Phân tích chi phí - lợi ích (ROI)

  • Giảm thiểu 100% chi phí in ấn phim chụp, bệnh án giấy truyền thống.
  • Cắt giảm ước tính 20 - 30% chi phí điều trị không cần thiết nhờ loại bỏ xét nghiệm lặp lại khi chuyển viện.
  • Thời gian thu hồi vốn đầu tư hạ tầng phần mềm ước tính trong vòng 12 - 18 tháng khi áp dụng trên quy mô liên minh 5 - 10 bệnh viện.

Hạn chế và hướng phát triển

Hạn chế kỹ thuật

  • Lưu trữ dữ liệu nhị phân dung lượng lớn: Hiện tại chỉ lưu trữ FHIR metadata trên chuỗi khối, chưa tích hợp hệ thống lưu trữ tệp phân tán liên kết (InterPlanetary File System - IPFS) để lưu trữ trực tiếp các tệp ảnh cắt lớp CT/PET-Scan hàng gigabyte.
  • Trải nghiệm người dùng: Việc quản lý chứng chỉ số cá nhân (Private Key/X.509) còn phức tạp đối với bệnh nhân lớn tuổi hoặc không am hiểu công nghệ.

Hướng phát triển

  • Tích hợp hệ thống lưu trữ phân tán IPFS kết hợp mã hóa bất đối xứng để quản lý toàn diện cả dữ liệu số liệu và hình ảnh chuẩn DICOM.
  • Ứng dụng công nghệ Bằng chứng không kiến thức (Zero-Knowledge Proofs - ZKP) để phục vụ các bài toán nghiên cứu thống kê dịch tễ học ung thư mà không làm lộ danh tính bệnh nhân.
  • Phát triển ứng dụng di động đa nền tảng tích hợp ví số sinh trắc học (Biometric Smart Wallet).

Đối tượng hưởng lợi

  • Sinh viên & Giảng viên ngành An toàn Thông tin / CNTT: Nguồn tài liệu tham khảo chi tiết về cách thiết lập mạng Hyperledger Fabric v2.2 native, cấu hình Raft Consensus và lập trình Smart Contract bằng Golang.
  • Lập trình viên & Kỹ sư hệ thống: Hiểu rõ phương pháp tích hợp chuẩn y tế HL7 FHIR vào kiến trúc hướng sự kiện (Event-driven Architecture) và cách triển khai Blockchain trên Kubernetes Rancher.
  • Các cơ sở y tế & Nhà quản lý bệnh viện: Bản thiết kế tham chiếu hoàn chỉnh để hiện thực hóa đề án bệnh án điện tử không giấy tờ theo thông tư của Bộ Y tế.
  • Bệnh nhân: Người hưởng lợi cao nhất khi quyền riêng tư sức khỏe được bảo vệ tối đa, nắm quyền sở hữu và cấp phát dữ liệu minh bạch.

Câu hỏi thường gặp

1. Yêu cầu kỹ thuật tối thiểu để một bệnh viện tham gia vào mạng Blockchain này là gì?

Mỗi bệnh viện cần tối thiểu 01 Node máy chủ (4 Cores CPU, 8GB RAM, 50GB dung lượng đĩa) chạy Docker và Kubernetes, cài đặt 01 Fabric CA riêng biệt đại diện cho Organization MSP và tối thiểu 01 Peer Node kết nối qua Mutual TLS vào Channel chung.

2. Giới hạn mở rộng (Scalability) của Hyperledger Fabric trong đề tài là bao nhiêu?

Với cơ chế đồng thuận Raft phân tách giữa pha thực thi (Endorsement) và pha tạo khối (Ordering), hệ thống đạt thông lượng hơn 300 TPS đối với truy vấn và hơn 120 TPS đối với cập nhật giao dịch. Khi số lượng bệnh viện tăng lên, việc mở rộng thêm nút chỉ làm tăng tải nhẹ ở pha Ordering và hoàn toàn có thể cân bằng tải thông qua cụm Kubernetes.

3. Hệ thống tích hợp với phần mềm quản lý bệnh viện (HIS/LIS) sẵn có như thế nào?

Hệ thống cung cấp tầng Middleware RESTful API chuẩn FHIR. Phần mềm HIS hiện tại của bệnh viện chỉ cần gọi các webhook/endpoint HTTP tiêu chuẩn (POST /records, GET /records) mà không cần thay đổi cấu trúc cơ sở dữ liệu nội bộ.

4. Dữ liệu y tế lưu trên Blockchain có vi phạm luật bảo vệ dữ liệu cá nhân không?

Không. Hệ thống tuân thủ mô hình Permissioned Blockchain: dữ liệu mã hóa chỉ chia sẻ nội bộ giữa các nút được cấp quyền trong Channel. Bệnh nhân có quyền thu hồi quyền đọc bất kỳ lúc nào thông qua Chaincode Access Control.

5. Chi phí vận hành mạng Blockchain này có tốn kém như Bitcoin hay Ethereum không?

Hoàn toàn không. Hyperledger Fabric là mạng riêng tư sử dụng thuật toán đồng thuận Raft (CFT), không sử dụng cơ chế đào coin (Mining/Proof-of-Work), do đó không tiêu tốn điện năng và không phát sinh phí gas cho mỗi giao dịch.

Kết luận

Đồ án khóa luận tốt nghiệp đã nghiên cứu và hiện thực hóa thành công Phương pháp chia sẻ bảo mật hồ sơ bệnh án điện tử FHIR bằng Blockchain, giải quyết triệt để các thách thức về bảo mật, toàn vẹn dữ liệu và tính tương thích trong ngành y tế. Sự kết hợp giữa chuẩn dữ liệu quốc tế HL7 FHIR, nền tảng phân tán Hyperledger Fabric v2.2 và công nghệ điều phối Kubernetes Rancher đã chứng minh tính khả thi cao cả về mặt lý thuyết lẫn thực nghiệm triển khai. Đây là bước tiến quan trọng mở ra tiềm năng ứng dụng sâu rộng của công nghệ chuỗi khối trong việc xây dựng hệ sinh thái y tế thông minh, an toàn và lấy bệnh nhân làm trung tâm.