Giới thiệu dự án

Lạm dụng thuốc kê đơn, đặc biệt là các dẫn xuất opioid, thuốc giảm đau hướng thần và thuốc an thần, đang là một trong những cuộc khủng hoảng y tế công cộng nghiêm trọng nhất trên toàn cầu. Theo báo cáo từ Tổ chức Y tế Thế giới (WHO) và Văn phòng Liên Hợp Quốc về Ma túy và Tội phạm (UNODC), các rối loạn liên quan đến sử dụng chất gây nghiện đã cướp đi sinh mạng của khoảng 128.000 người vào năm 2019, trong đó opioid chiếm gần 70% số ca tử vong và chiếm 71% trong tổng số 18 triệu năm sống điều chỉnh theo mức độ tàn tật (DALYs) bị mất đi. Tại Việt Nam và nhiều quốc gia, các loại thuốc kê đơn thuộc danh mục kiểm soát đặc biệt đòi hỏi quy trình giám sát nghiêm ngặt từ khâu chẩn đoán, kê đơn cho đến phân phối tại các cơ sở bán lẻ thuốc.

+-----------------------------------------------------------------------------------+
|               BỐI CẢNH KHỦNG HOẢNG LẠM DỤNG THUỐC KÊ ĐƠN & OPIOID                 |
+-----------------------------------------------------------------------------------+
|  128.000 Ca tử vong do rối loạn chất (2019)  --->  Opioid chiếm gần 70%           |
|  18 Triệu năm sống khỏe mạnh bị mất (DALYs)   --->  Opioid chiếm 71%              |
|  Hành vi trục lợi chính: "Doctor Shopping" & Gian lận/Làm giả đơn thuốc vật lý     |
+-----------------------------------------------------------------------------------+

Thực trạng này xuất phát từ hai bài toán nhức nhối:

  • Tình trạng "Doctor Shopping" (Đi khám nhiều bác sĩ): Bệnh nhân đến nhiều cơ sở khám chữa bệnh khác nhau trong thời gian ngắn để nhận nhiều đơn thuốc cho cùng một bệnh lý nhằm tích trữ hoặc lạm dụng thuốc gây nghiện. Do các cơ sở y tế hoạt động trên các hệ thống thông tin bệnh viện (HIS/EMR) độc lập và biệt lập (data silos), bác sĩ không thể tiếp cận lịch sử kê đơn tổng thể của bệnh nhân từ các nguồn bên ngoài.
  • Gian lận phân phối và tái sử dụng đơn thuốc: Thiếu cơ chế đồng bộ và xác thực thời gian thực giữa bác sĩ kê đơn và các nhà thuốc độc lập dẫn đến việc một đơn thuốc có thể bị quay vòng mua nhiều lần tại các quầy thuốc khác nhau hoặc bị làm giả mạo chứng từ y tế.

Để giải quyết triệt để các rào cản trên, đồ án tốt nghiệp ngành An toàn Thông tin của sinh viên Trần Đức Minh (Trường Đại học Công nghệ Thông tin - ĐHQG TP.HCM, dưới sự hướng dẫn của ThS. Trần Tuấn Dũng và ThS. Bùi Thanh Bình) đã nghiên cứu và phát triển Medichain — Hệ thống quản lý và phân phối thuốc kê đơn sử dụng công nghệ giao tiếp đa chuỗi khối (Cross-chain) và Bằng chứng không kiến thức (Zero-Knowledge Proofs - ZKP).

+-----------------------------------------------------------------------------------+
|                                 MỤC TIÊU DỰ ÁN                                    |
+-----------------------------------------------------------------------------------+
| 1. Thiết lập kiến trúc Multi-chain / Sidechain liên kết các hệ thống không đồng nhất |
| 2. Chuẩn hóa đơn thuốc điện tử thành tài sản kỹ thuật số duy nhất qua ERC-721 NFT  |
| 3. Bảo vệ dữ liệu nhạy cảm bệnh nhân bằng thuật toán ZKP (zk-SNARKs Groth16)      |
| 4. Triển khai logic quản trị chống gian lận thông qua Smart Contracts              |
+-----------------------------------------------------------------------------------+

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

Medichain đóng vai trò như một mạng lưới Sidechain/Relay-chain trung gian, kết nối các blockchain riêng rẽ của từng bệnh viện (như Ethereum Public/Testnet và Quorum Enterprise). Đơn thuốc được số hóa dưới dạng Non-Fungible Token (NFT) theo chuẩn ERC-721 nhưng chỉ lưu trữ các siêu dữ liệu quản trị (metadata) và giá trị băm (hash), hoàn toàn loại bỏ thông tin bệnh án nhạy cảm trên sổ cái công khai. Việc xác minh tính hợp lệ của đơn thuốc được thực hiện thông qua giao thức zk-SNARKs, mã hóa bất đối xứng và kiểm tra hàm băm mật mã học Keccak-256.

+------------------------------------------------------------------------------------+
|                                KẾT QUẢ KỲ VỌNG                                     |
+------------------------------------------------------------------------------------+
| - Loại bỏ 100% tình trạng mua thuốc trùng lặp qua ràng buộc thời gian (Lock Time)  |
| - Ngăn chặn hoàn toàn hành vi giả mạo hoặc sửa đổi nội dung đơn thuốc              |
| - Bảo mật 100% dữ liệu y tế nhạy cảm của bệnh nhân theo tiêu chuẩn HIPAA/GDPR      |
| - Thời gian thực thi xác thực giao dịch liên chuỗi đạt mức < 3 giây                |
+------------------------------------------------------------------------------------+

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

Đồ án tập trung thiết kế và triển khai thực nghiệm môi trường liên chuỗi gồm hai mạng blockchain đại diện cho hai cơ sở y tế độc lập (Ethereum và GoQuorum), cùng một chuỗi trung gian Medichain. Hệ thống tập trung giải quyết quy trình xác thực đơn thuốc, kiểm soát thời gian chờ cấp phát và bảo mật danh tính, không bao gồm việc lưu trữ dung lượng lớn toàn bộ hồ sơ chẩn đoán hình ảnh (DICOM) on-chain.

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

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

Các mô hình lưu trữ và quản lý hồ sơ y tế điện tử (EHR/EMR) hiện nay đối mặt với nhiều bất cập lớn về tính toàn vẹn, khả năng chia sẻ dữ liệu liên cơ sở và bài toán bảo vệ quyền riêng tư người dùng.

+----------------------------------------------------------------------------------------------------+
|                           SO SÁNH CÁC GIẢI PHÁP QUẢN LÝ ĐƠN THUỐC                                  |
+----------------------+-----------------------------+-----------------------+-----------------------+
| Tiêu chí             | Hệ thống tập trung (HIS/EMR)| HealthChain [12]      | Medichain (Đề xuất)   |
+----------------------+-----------------------------+-----------------------+-----------------------+
| Kiến trúc hệ thống   | Máy chủ Client-Server       | Single Blockchain     | Multi-chain Sidechain |
|                      | tập trung                   | (IPFS + CouchDB)      | (Relay Architecture)  |
+----------------------+-----------------------------+-----------------------+-----------------------+
| Bảo vệ quyền         | Kiểm soát truy cập          | Mã hóa khóa công khai | ZKP (zk-SNARKs) +     |
| riêng tư             | mức cơ sở dữ liệu           | đối xứng/bất đối xứng | Metadata Hashing      |
+----------------------+-----------------------------+-----------------------+-----------------------+
| Liên thông bệnh viện | Kém (Phụ thuộc API riêng lẻ)| Hạn chế (Xung đột lợi | Cao (Cơ chế liên      |
|                      | gây ra Data Silos)          | ích khi lưu chung)    | chuỗi độc lập)        |
+----------------------+-----------------------------+-----------------------+-----------------------+
| Chống Doctor         | Thấp (Không có cơ chế       | Trung bình (Chỉ trong | Tuyệt đối (Khóa tự    |
| Shopping             | khóa liên cơ sở)            | một mạng đơn lẻ)      | động bằng Smart Ctr)  |
+----------------------+-----------------------------+-----------------------+-----------------------+
| Điểm nghẽn lỗi (SPOF)| Có (Dễ bị tấn công DDoS,    | Không                 | Không (Mạng lưới phân |
|                      | rò rỉ dữ liệu máy chủ)      |                       | tán đa thành phần)    |
+----------------------+-----------------------------+-----------------------+-----------------------+

Phân tích yêu cầu hệ thống theo mô hình MoSCoW

  • Must Have (Bắt buộc có):
    • Token hóa đơn thuốc thành chuẩn ERC-721 định danh duy nhất (P_{ID}).
    • Kiểm tra tính toàn vẹn thông qua đối soát mã băm mật mã: $\text{hash}(P_{De}) == P_H$.
    • Cơ chế khóa thời gian chờ cấp phát tối thiểu ($P_{LockT}$) và kiểm tra ngày hết hạn ($P_{ExpDate}$).
    • Giao thức mã hóa bất đối xứng truyền tải dữ liệu chi tiết đơn thuốc giữa Bác sĩ, Bệnh nhân và Cơ sở y tế.
  • Should Have (Nên có):
    • Tích hợp mạch số học ZKP để xác thực điều kiện cấp thuốc mà không để lộ chi tiết bệnh lý.
    • Hỗ trợ cơ chế Relay Chain / Notary Bridge để trung chuyển trạng thái giao dịch giữa các chuỗi EVM-compatible.
  • Could Have (Có thể có):
    • Tích hợp ZK-Rollups để gom nhóm (batching) hàng nghìn giao dịch xác nhận đơn thuốc nhằm tối ưu hóa gas fee.
    • Quản lý định danh phi tập trung (Decentralized Identifiers - DID) cho bác sĩ và cơ sở y tế.
  • Won't Have (Chưa thực hiện trong phạm vi này):
    • Lưu trữ trực tiếp toàn bộ dữ liệu xét nghiệm, hình ảnh y khoa dung lượng lớn trên Layer 1.

Thiết kế hệ thống

Kiến trúc Medichain được cấu trúc thành mô hình đa tầng phân tán nhằm đảm bảo tính toàn vẹn dữ liệu, hiệu năng cao và bảo mật tối đa cho toàn bộ các thực thể tham gia.

+-----------------------------------------------------------------------------------+
|                         KIẾN TRÚC TỔNG THỂ HỆ THỐNG MEDICHAIN                     |
+-----------------------------------------------------------------------------------+
| [1] USER LAYER:                                                                   |
|     +------------------+    +--------------------+    +-----------------------+   |
|     |  Bác sĩ (Doctor) |    | Bệnh nhân (Patient)|    |  Nhà thuốc (Pharmacy) |   |
|     +--------+---------+    +---------+----------+    +-----------+-----------+   |
|              |                        |                           |               |
| [2] NODE LAYER:                       |                           |               |
|     +--------v------------------------v---------------------------v-----------+   |
|     | Cơ sở y tế A (Validator Node)   |  Cơ sở y tế B (Validator Node)        |   |
|     | Chuỗi Quorum nội bộ (Bệnh viện) |  Chuỗi Ethereum Testnet (Phòng khám)  |   |
|     +---------------------------------+---------------------------------------+   |
|                                       |                                           |
| [3] RELAY & SMART CONTRACT LAYER (Medichain Core):                                |
|     +-------------------------------------------------------------------------+   |
|     | - ERC-721 Prescription NFT Contract (Quản trị trạng thái đơn thuốc)     |   |
|     | - ZKP Verifier Contract (Groth16 Verifier on alt_bn128 Curve)           |   |
|     | - Cross-Chain Relay Manager (Đồng bộ trạng thái Notary / Sidechain)     |   |
|     +-------------------------------------------------------------------------+   |
|                                       |                                           |
| [4] OFF-CHAIN DATA STORAGE LAYER:                                                 |
|     +-------------------------------------------------------------------------+   |
|     | Local Hospital Encrypted Database (CouchDB / Enterprise Private DB)     |   |
+-----------------------------------------------------------------------------------+

Technology Stack và phiên bản kỹ thuật

  • Smart Contract Language: Solidity ^0.8.20 (Sử dụng OpenZeppelin ERC-721 standard contracts).
  • Core Blockchain Networks:
    • Public/Testnet Chain: Ethereum Sepolia / Go-Ethereum (Geth v1.13.x).
    • Enterprise Consortium Chain: GoQuorum v23.4.0 (Cơ chế đồng thuận IBFT 2.0 / QBFT).
    • Intermediary Sidechain: Medichain Relay Node.
  • Zero-Knowledge Proof Framework: ZoKrates v0.8.8 (Chứng minh zk-SNARKs giao thức Groth16, đường cong elip alt_bn128 / BN254).
  • Client & Backend Integration: Node.js v18 LTS, Ethers.js v6.x, Web3.js v4.x.
  • Off-chain Database: CouchDB v3.3 kết hợp mã hóa cấp bản ghi AES-256-GCM.

Cấu trúc dữ liệu siêu dữ liệu đơn thuốc (ERC-721 Metadata JSON)

Để đảm bảo quyền riêng tư, cấu trúc NFT đại diện cho đơn thuốc trên Medichain chỉ lưu giữ các định danh và giá trị băm:

{
  "title": "Medichain Prescription NFT Metadata",
  "type": "object",
  "properties": {
    "tokenId": { "type": "string", "description": "Mã định danh duy nhất của NFT đơn thuốc (P_ID)" },
    "ownerId": { "type": "string", "description": "Địa chỉ ví hoặc ID của Bệnh nhân sở hữu (P_OID)" },
    "storageAddress": { "type": "string", "description": "Địa chỉ trỏ đến Cơ sở y tế lưu bản gốc (P_LocAddr)" },
    "mintDate": { "type": "uint256", "description": "Timestamp thời điểm bác sĩ kê đơn (P_MintDate)" },
    "expirationDate": { "type": "uint256", "description": "Timestamp thời điểm đơn thuốc hết hiệu lực (P_ExpDate)" },
    "waitingTime": { "type": "uint256", "description": "Khoảng thời gian chờ tối thiểu giữa 2 lần lấy thuốc (P_LockT)" },
    "prescriptionHash": { "type": "string", "description": "Mã băm Keccak-256 của toàn bộ chi tiết thuốc (P_H)" }
  }
}

Methodology

Dự án được xây dựng và triển khai theo phương pháp luận phát triển phần mềm linh hoạt (Agile/Scrum) với 4 giai đoạn trọng tâm:

+------------------------------------------------------------------------------------+
|                         LỘ TRÌNH TRIỂN KHAI PHÁT TRIỂN (SPRINTS)                   |
+------------------------------------------------------------------------------------+
| Sprint 1: Khảo sát quy trình nghiệp vụ kê đơn, xây dựng mô hình đe dọa an toàn    |
| Sprint 2: Thiết kế Smart Contracts Solidity (ERC-721) và mạch số học ZKP ZoKrates  |
| Sprint 3: Triển khai mạng GoQuorum & Ethereum Testnet, xây dựng cầu nối Relay      |
| Sprint 4: Kiểm thử bảo mật, benchmark hiệu năng, đo lường chi phí gas và độ trễ    |
+------------------------------------------------------------------------------------+

Đánh giá rủi ro và chiến lược giảm thiểu (Risk Assessment)

  • Rủi ro rò rỉ dữ liệu bệnh án: Giảm thiểu bằng kiến trúc không lưu dữ liệu thô on-chain; chỉ lưu $P_H = \text{Keccak256}(P_{De})$. Toàn bộ dữ liệu trao đổi off-chain được mã hóa bất đối xứng qua public key của bên nhận.
  • Rủi ro nghẽn mạng và chi phí gas cao: Giảm thiểu bằng việc đưa phần lớn nghiệp vụ xác thực về mạng Consortium GoQuorum với cơ chế đồng thuận QBFT (không tốn gas phí giao dịch) và sử dụng Sidechain Relay cho việc liên lạc giữa các chuỗi.
  • Rủi ro tấn công lặp lại (Replay Attacks) trên liên chuỗi: Bổ sung trường nonce, chữ ký số định danh và kiểm tra timestamp trên từng giao dịch cross-chain.

Implementation và kết quả

Development process

Trọng tâm kỹ thuật của Medichain nằm ở việc kết hợp giữa hợp đồng thông minh quản lý vòng đời đơn thuốc và giao thức truyền tin bảo mật.

1. Thuật toán truy vấn và cấp phát đơn thuốc bảo mật

Quy trình truy xuất thông tin chi tiết đơn thuốc mà không công khai dữ liệu trên blockchain được mô tả chi tiết qua thuật toán sau:

======================================================================================
THUẬT TOÁN: TRUY VẤN VÀ CẤP PHÁT ĐƠN THUỐC BẢO MẬT (Algorithmic Protocol)
======================================================================================
Đầu vào: Bác sĩ/Nhà thuốc (D/Pa), Bệnh nhân (U), Cơ sở y tế (Me), NFT đơn thuốc (P)
Đầu ra: Chi tiết đơn thuốc giải mã P_{De} hợp lệ, giao dịch cấp thuốc thành công TX_{dispense}

Bước 1 (Yêu cầu truy cập):
  - D (hoặc Pa) gửi yêu cầu đọc chi tiết đơn thuốc P_{De} đến Bệnh nhân U.
  - Gửi kèm thông tin xác thực Cred_{ID} và Khóa công khai PK_D.
  - Kiểm tra điều kiện: Me_{Addr} == P_{LocAddr} và Cred_{ID} của U == P_{OID}.

Bước 2 (Bệnh nhân ủy quyền):
  - Bệnh nhân U ký số giao dịch chấp thuận cho phép D hoặc Pa truy cập.

Bước 3 (Mã hóa và truyền dữ liệu):
  - Cơ sở y tế Me nhận tín hiệu ủy quyền, tiến hành lấy P_{De} từ cơ sở dữ liệu nội bộ.
  - Me mã hóa: Encrypted_Data E_P = Encrypt_{PK_D}(P_{De}).
  - Me gửi E_P trực tiếp đến D (hoặc Pa) qua kênh truyền bảo mật (P2P/TLS).

Bước 4 (Giải mã và kiểm tra tính toàn vẹn):
  - D (hoặc Pa) giải mã bằng Khóa bí mật: P_{De} = Decrypt_{SK_D}(E_P).
  - Thực hiện kiểm tra tính toàn vẹn mật mã:
      if Keccak256(P_{De}) == P_H then
          Chấp nhận đơn thuốc là hợp lệ và nguyên bản.
      else
          Hủy bỏ phiên làm việc, cảnh báo gian lận dữ liệu!

Bước 5 (Cấp phát và khóa đơn thuốc):
  - Nhà thuốc Pa kiểm tra: block.timestamp <= P_{ExpDate} VÀ block.timestamp >= TX_{Last} + P_{LockT}
  - Gọi Smart Contract cập nhật trạng thái TX_{Last} = block.timestamp.
======================================================================================

2. Cấu trúc Smart Contract thực thi quản trị đơn thuốc (Solidity Code Snippet)

Dưới đây là đoạn mã nguồn thực thi chức năng đúc đơn thuốc (Minting) và xác thực điều kiện cấp thuốc trên Medichain:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
import "@openzeppelin/contracts/access/Ownable.sol";

interface IZkVerifier {
    function verifyTx(bytes calldata proof, uint[2] memory input) external view returns (bool);
}

contract MedichainPrescription is ERC721, Ownable {
    struct PrescriptionData {
        address patientAddress;
        address hospitalAddress;
        uint256 mintDate;
        uint256 expirationDate;
        uint256 lockTime;
        uint256 lastDispensedTime;
        bytes32 prescriptionHash;
    }

    uint256 private _nextTokenId;
    IZkVerifier public zkVerifier;
    mapping(uint256 => PrescriptionData) public prescriptions;

    event PrescriptionMinted(uint256 indexed tokenId, address indexed patient, bytes32 pHash);
    event MedicationDispensed(uint256 indexed tokenId, address indexed pharmacy, uint256 timestamp);

    constructor(address _zkVerifierAddress) ERC721("MedichainPrescription", "MCP") Ownable(msg.sender) {
        zkVerifier = IZkVerifier(_zkVerifierAddress);
    }

    function mintPrescription(
        address patient,
        uint256 expDate,
        uint256 lockT,
        bytes32 pHash
    ) external returns (uint256) {
        require(expDate > block.timestamp, "Invalid expiration date");
        uint256 tokenId = ++_nextTokenId;
        
        _safeMint(patient, tokenId);
        prescriptions[tokenId] = PrescriptionData({
            patientAddress: patient,
            hospitalAddress: msg.sender,
            mintDate: block.timestamp,
            expirationDate: expDate,
            lockTime: lockT,
            lastDispensedTime: 0,
            prescriptionHash: pHash
        });

        emit PrescriptionMinted(tokenId, patient, pHash);
        return tokenId;
    }

    function dispenseMedication(
        uint256 tokenId, 
        bytes calldata zkProof, 
        uint[2] memory zkPublicInputs
    ) external {
        PrescriptionData storage p = prescriptions[tokenId];
        require(block.timestamp <= p.expirationDate, "Prescription expired");
        require(block.timestamp >= p.lastDispensedTime + p.lockTime, "Anti-Doctor-Shopping lock active");
        
        // Xác thực ZKP on-chain (Groth16 Verifier)
        require(zkVerifier.verifyTx(zkProof, zkPublicInputs), "Invalid ZK Proof");

        p.lastDispensedTime = block.timestamp;
        emit MedicationDispensed(tokenId, msg.sender, block.timestamp);
    }
}

Testing và validation

Hệ thống đã trải qua quá trình kiểm thử toàn diện trên cả môi trường thử nghiệm chức năng và môi trường đo kiểm hiệu năng thực tế.

+------------------------------------------------------------------------------------+
|                         KẾT QUẢ ĐO KIỂM HIỆU NĂNG (BENCHMARK DATA)                 |
+------------------------------------+-----------------------+-----------------------+
| Chỉ số đo lường (Metrics)          | Môi trường Ethereum   | Môi trường GoQuorum   |
|                                    | Sepolia Testnet       | IBFT 2.0 (Consortium) |
+------------------------------------+-----------------------+-----------------------+
| Gas tiêu thụ: Mint Prescription NFT| ~142,580 gas          | 0 gas (Enterprise)    |
| Gas tiêu thụ: Groth16 ZKP Verify   | ~218,450 gas          | 0 gas (Enterprise)    |
| Thời gian tạo Proof (Client ZK)    | 1.18 giây             | 1.18 giây             |
| Thời gian xác thực Proof On-chain  | 12.4 ms               | 4.2 ms                |
| Độ trễ giao dịch liên chuỗi (Relay)| 2.85 giây             | 0.95 giây             |
| Khả năng chịu tải thông lượng (TPS)| ~15 - 25 TPS          | ~450 - 600 TPS        |
+------------------------------------+-----------------------+-----------------------+

+-----------------------------------------------------------------------------------+
|                           KẾT QUẢ KIỂM THỬ AN TOÀN BẢO MẬT                        |
+-----------------------------------------------------------------------------------+
| 1. Tấn công Replay / Tái cấp phát thuốc (Double-dispensing):                      |
|    --> KẾT QUẢ: 100% Giao dịch vi phạm bị Revert bởi ràng buộc `P_{LockT}`        |
|                                                                                   |
| 2. Tấn công Giả mạo đơn thuốc (Tampering Payload):                                |
|    --> KẾT QUẢ: Bị chặn ngay lập tức do sai khớp giá trị `Keccak256(P_{De})`      |
|                                                                                   |
| 3. Tấn công Đọc trộm dữ liệu bệnh án trên Blockchain Explorer:                   |
|    --> KẾT QUẢ: Tuyệt đối an toàn (Chỉ hiển thị Hash $P_H$ và TokenId vô nghĩa)   |
+-----------------------------------------------------------------------------------+

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

+-----------------------------------------------------------------------------------+
|                        MỤC TIÊU BAN ĐẦU vs KẾT QUẢ ĐẠT ĐƯỢC                       |
+---------------------------------------------------+-------------------------------+
| Mục tiêu đề ra                                    | Kết quả thực nghiệm           |
+---------------------------------------------------+-------------------------------+
| - Ngăn chặn triệt để hành vi Doctor Shopping      | ĐẠT (Kiểm soát 100% bằng Lock)|
| - Bảo mật danh tính và bệnh án bệnh nhân          | ĐẠT (Ứng dụng ZKP + Hash)     |
| - Kết nối hệ thống y tế không đồng nhất           | ĐẠT (Liên chuỗi ETH + Quorum) |
| - Thời gian phản hồi nghiệp vụ < 3s               | ĐẠT (Độ trễ trung bình 1.8s)  |
+---------------------------------------------------+-------------------------------+

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

  1. Kiến trúc phân tách trạng thái và siêu dữ liệu (Decoupled State-Data Architecture): Thay vì lưu toàn bộ đơn thuốc lên chuỗi gây tắc nghẽn và vi phạm quyền riêng tư, Medichain tiên phong sử dụng mô hình ERC-721 Representation Token. Đơn thuốc on-chain chỉ là một vé định danh chứa ràng buộc pháp lý, trong khi dữ liệu chi tiết vẫn nằm tại cơ sở y tế gốc.

  2. Ứng dụng mật mã học không kiến thức (zk-SNARKs Groth16) trong chuỗi cung ứng y tế: Cho phép nhà thuốc xác minh điều kiện cấp phát (như đơn thuốc còn trong hạn, đúng danh mục, bệnh nhân đủ điều kiện nhận) mà không cần xem toàn bộ lịch sử bệnh lý chi tiết của người bệnh.

  3. Cơ chế liên chuỗi giải quyết bài toán xung đột lợi ích giữa các bệnh viện: Các bệnh viện lớn có thể tự duy trì mạng Private Blockchain riêng (GoQuorum) để đảm bảo chủ quyền dữ liệu, nhưng vẫn đồng bộ được trạng thái chống lạm dụng thuốc thông qua mạng liên kết Medichain Relay.

+-----------------------------------------------------------------------------------+
|                    TỔNG HỢP CÁC CẢI TIẾN HIỆU QUẢ CỦA MEDICHAIN                   |
+-----------------------------------------------------------------------------------+
| [X] Giảm 100% nguy cơ trùng lặp đơn thuốc trên toàn bộ hệ thống quầy thuốc        |
| [X] Giảm 92% dung lượng lưu trữ on-chain so với mô hình lưu trữ EMR truyền thống  |
| [X] Rút ngắn thời gian xác thực tính hợp lệ của đơn thuốc từ vài giờ xuống < 2s  |
+-----------------------------------------------------------------------------------+

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

Kịch bản sử dụng thực tế (Real-world Scenario)

  1. Khám bệnh: Bệnh nhân $U$ đến Bệnh viện A được Bác sĩ $D$ kê đơn giảm đau Opioid trong 7 ngày. Bác sĩ khởi tạo đơn thuốc với LockTime = 7 ngày. Hệ thống đúc NFT đơn thuốc tương ứng trên Medichain.
  2. Mua thuốc tại Nhà thuốc X: Bệnh nhân xuất trình định danh NFT. Nhà thuốc X xác thực on-chain qua ZKP, cấp thuốc cho 7 ngày đầu tiên và hệ thống tự động kích hoạt trạng thái khóa.
  3. Ngăn chặn Doctor Shopping tại Bệnh viện B: Ngày hôm sau, bệnh nhân đến Bệnh viện B yêu cầu bác sĩ khác kê thêm đơn thuốc tương tự. Khi bác sĩ tại Bệnh viện B truy vấn Medichain, hệ thống từ chối cho phép cấp đơn mới do đơn thuốc cũ đang trong thời gian $P_{LockT}$, ngăn chặn hoàn toàn hành vi lạm dụng.
+-----------------------------------------------------------------------------------+
|                        MÔ HÌNH TRIỂN KHAI HỆ THỐNG DOANH NGHIỆP                   |
+-----------------------------------------------------------------------------------+
|  [Bệnh viện / Cơ sở khám chữa bệnh]   ---> Chạy GoQuorum Validator Node           |
|  [Chuỗi Nhà thuốc lớn / Trung tâm]    ---> Chạy Medichain Member Node             |
|  [Nhà thuốc bán lẻ / Quầy thuốc nhỏ]  ---> Sử dụng Web3 Portal qua REST API       |
|  [Người bệnh / Bác sĩ]                ---> Thao tác qua Medichain Mobile DApp     |
+-----------------------------------------------------------------------------------+

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

  • Tiết kiệm ngân sách bảo hiểm y tế: Loại trừ các chi phí chi trả trùng lặp cho các đơn thuốc bị lạm dụng hoặc gian lận bảo hiểm.
  • Chi phí vận hành tối thiểu: Do sử dụng mạng Consortium GoQuorum cho các giao dịch nội bộ, chi phí phí gas (transaction fee) thực tế tiệm cận mức 0 USD.

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

Hạn chế kỹ thuật hiện tại

  • Phụ thuộc vào quy trình khởi tạo ban đầu đáng tin cậy (Trusted Setup) của thuật toán zk-SNARKs Groth16.
  • Đòi hỏi các cơ sở y tế phải duy trì hạ tầng node mạng ổn định và chuẩn hóa giao tiếp API.

Hướng phát triển trong tương lai

  • Nâng cấp công nghệ ZK: Chuyển dịch sang zk-STARKs hoặc Halo2 nhằm loại bỏ hoàn toàn yêu cầu Trusted Setup, nâng cao tốc độ sinh bằng chứng trên thiết bị di động.
  • Tích hợp giải pháp mở rộng ZK-Rollups (Layer 2): Sử dụng các kiến trúc Rollups hiện đại (như zkSync Era, Starknet) để nén hàng chục nghìn giao dịch đơn thuốc vào một proof duy nhất, nâng thông lượng hệ thống lên > 2.000 TPS.
  • Tích hợp W3C Verifiable Credentials (VC) và Decentralized Identifiers (DID): Chuẩn hóa danh tính điện tử cho bác sĩ và dược sĩ trên quy mô toàn quốc.

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

+------------------------------------------------------------------------------------+
|                         LỢI ÍCH DÀNH CHO CÁC NHÓM ĐỐI TƯỢNG                        |
+----------------------+-------------------------------------------------------------+
| Đối tượng            | Giá trị và Lợi ích định lượng mang lại                      |
+----------------------+-------------------------------------------------------------+
| Sinh viên & Học viên | - Tài liệu tham khảo toàn diện về tích hợp Multi-chain & ZKP|
|                      | - Mô hình mẫu về việc ứng dụng Smart Contract vào Y tế      |
+----------------------+-------------------------------------------------------------+
| Kỹ sư Blockchain     | - Kiến trúc mẫu triển khai Cross-chain Relay và GoQuorum    |
|                      | - Mẫu code Smart Contract ERC-721 kết hợp Verifier ZoKrates |
+----------------------+-------------------------------------------------------------+
| Bệnh viện & Nhà thuốc| - Hệ thống theo dõi minh bạch, loại bỏ thất thoát thuốc     |
|                      | - Tuân thủ tuyệt đối quy định bảo mật dữ liệu y tế (HIPAA)  |
+----------------------+-------------------------------------------------------------+
| Cơ quan quản lý Y tế | - Công cụ giám sát thời gian thực việc lưu hành thuốc độc   |
|                      | - Dữ liệu thống kê chuẩn xác, bất biến phục vụ chính sách   |
+----------------------+-------------------------------------------------------------+

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

1. Yêu cầu kỹ thuật phần cứng để triển khai một Validator Node Medichain tại bệnh viện là gì?

Cơ sở y tế cần máy chủ tiêu chuẩn: CPU 4 cores (x86_64), 8GB RAM, 100GB SSD dung lượng lưu trữ, hệ điều hành Ubuntu 22.04 LTS và cài đặt môi trường Docker/Docker Compose để vận hành GoQuorum Node cùng Medichain Relay Agent.

2. Hệ thống xử lý thế nào trong trường hợp bệnh nhân gặp tình huống cấp cứu cần dùng thuốc ngay mà đơn cũ vẫn đang trong thời gian chờ ($P_{LockT}$)?

Medichain hỗ trợ Giao thức khẩn cấp (Emergency Override Protocol). Khi có xác nhận chữ ký số của ít nhất 2 bác sĩ trưởng khoa cấp cứu hoặc người quản trị bệnh viện, Smart Contract cho phép đặt lại thời gian chờ ($TX_{ResetTm}$) và ghi nhận sự kiện đặc biệt này vào sổ cái để phục vụ công tác thanh tra y tế sau đó.

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

Medichain cung cấp bộ thư viện SDK (Node.js/Python) và RESTful API Gateway bảo mật. Phần mềm HIS hiện tại chỉ cần gọi API đúc đơn thuốc khi bác sĩ nhấn nút "Kê đơn" trên giao diện phần mềm quen thuộc mà không cần thay đổi cấu trúc cơ sở dữ liệu nội bộ.

4. Chi phí duy trì hệ thống và phí giao dịch (Gas Fee) được tính toán như thế nào?

Mạng lưới cốt lõi vận hành trên nền tảng GoQuorum Consortium do liên minh các cơ sở y tế vận hành theo cơ chế Proof of Authority (PoA/QBFT), do đó phí gas bằng 0. Chi phí duy trì duy nhất là điện năng và đường truyền máy chủ sẵn có của bệnh viện.

5. Dữ liệu bệnh án của bệnh nhân có nguy cơ bị lộ khi cơ sở y tế bị tấn công mạng không?

Toàn bộ chi tiết đơn thuốc lưu trữ tại cơ sở y tế được mã hóa AES-256-GCM. Ngay cả khi tin tặc chiếm quyền kiểm soát máy chủ dữ liệu hoặc đọc dữ liệu trên Blockchain Explorer, chúng chỉ thấy các chuỗi băm $P_H$ và các bằng chứng ZKP không chứa thông tin đọc được.

Kết luận

Đồ án tốt nghiệp Medichain của tác giả Trần Đức Minh đã giải quyết thành công một trong những thách thức phức tạp nhất của y tế hiện đại: kiểm soát chuỗi cung ứng và phân phối thuốc kê đơn đặc biệt mà không làm phương hại đến quyền riêng tư của người bệnh. Bằng sự kết hợp chặt chẽ giữa Công nghệ Blockchain đa chuỗi (Multi-chain), Chuẩn tài sản số ERC-721 và Mật mã học không kiến thức (zk-SNARKs Groth16), nghiên cứu đã xây dựng một khuôn khổ kỹ thuật vững chắc, có tính khả thi cao và sẵn sàng đáp ứng yêu cầu chuyển đổi số y tế an toàn, minh bạch trong tương lai.