Giới thiệu dự án

Trong kỷ nguyên chuyển đổi số y tế, việc liên thông và bảo mật hồ sơ sức khỏe điện tử đóng vai trò sống còn đối với chất lượng chẩn đoán và điều trị. Theo báo cáo từ Tổ chức Y tế Thế giới (WHO), mặc dù tỷ lệ bao phủ chăm sóc sức khỏe toàn dân (Universal Health Coverage - UHC) đạt mức 68% vào năm 2021, nhưng tốc độ cải thiện đã chững lại rõ rệt kể từ năm 2015, để lại khoảng 4,5 tỷ người trên toàn cầu chưa được tiếp cận đầy đủ các dịch vụ y tế thiết yếu. Một trong những rào cản kỹ thuật lớn nhất là sự phân mảnh dữ liệu giữa các cơ sở y tế độc lập.

+-----------------------------------------------------------------------------------+
|                              HỆ SINH THÁI MIDAS                                    |
|                                                                                   |
|  +-------------------+       +-----------------------+       +-----------------+  |
|  |   Hospital A      |       |     MIDAS RELAY       |       |   Hospital N    |  |
|  |  Private Chain    |<----->|  Decentralized Oracle |<----->|  Private Chain  |  |
|  | (Smart Contract A)|       | (Oracle Contract - OC)|       |(Smart Contract N|  |
|  +--------+----------+       +-----------+-----------+       +--------+--------+  |
|           |                              |                            |           |
|           v                              v                            v           |
|      [Local EMR]                [BIDI Directory Service]         [Local EMR]      |
|                                (ADir / ODir on IPFS)                              |
+-----------------------------------------------------------------------------------+

Bài toán thực tế và thách thức

Khi bệnh nhân thăm khám tại nhiều bệnh viện, mỗi cơ sở y tế lại tạo ra một Hồ sơ Y tế Điện tử (Electronic Medical Record - EMR) độc lập trên hệ thống nội bộ. Việc các bệnh viện triển khai công nghệ Blockchain riêng biệt (Private/Consortium Blockchain) tạo ra những "ốc đảo dữ liệu" (data silos) khép kín. Các thách thức kỹ thuật cốt lõi bao gồm:

  1. Thiếu khả năng tương tác đa chuỗi (Cross-chain Inoperability): Các mạng Blockchain có kiến trúc, máy ảo (EVM/WASM) và thuật toán đồng thuận khác nhau không thể trực tiếp đọc hoặc ghi dữ liệu chéo mà không có cơ chế bắc cầu an toàn.
  2. Quản lý định danh rời rạc: Việc thiếu vắng một chuẩn danh tính phân tán đa chuỗi khiến việc liên kết danh tính người bệnh với toàn bộ các hồ sơ EMR phân tán trở nên phức tạp, dễ dẫn đến nhầm lẫn hoặc rò rỉ Thông tin Định danh Cá nhân (Personally Identifiable Information - PII / PHI).
  3. Kiểm soát truy cập thủ công: Chưa có cơ chế tự động hóa phân quyền truy cập hồ sơ bệnh án xuyên biên giới giữa các mạng Blockchain độc lập theo thời gian thực.

Mục tiêu nghiên cứu

Dự án khóa luận tốt nghiệp ngành An toàn Thông tin với đề tài "MIDAS: Hệ thống quản lý dữ liệu và truy cập tương tác đa chuỗi trong lĩnh vực chăm sóc sức khỏe" đặt ra các mục tiêu cụ thể:

  1. Thiết kế và triển khai kiến trúc tương tác liên chuỗi (Cross-chain Interoperability) dựa trên mô hình Relay/Sidechain và Mạng Oracle phi tập trung (Decentralized Oracle Network).
  2. Xây dựng mô hình định danh số phi tập trung liên chuỗi mang tên BIDI (Blockchain Interoperability Decentralized Identifier) nhằm gắn kết thực thể bệnh nhân, bác sĩ và hồ sơ EMR đa nguồn.
  3. Tự động hóa kiểm soát quyền truy cập thông qua Hợp đồng Thông minh (Smart Contract - SC) và hệ thống thư mục phân quyền (BIDI Directory: ADir, ODir) lưu trữ phân tán trên IPFS.
  4. Đảm bảo tính toàn vẹn (Integrity), tính bí mật (Confidentiality) và khả năng sẵn sàng (Availability) của dữ liệu y tế với chi phí tính toán và độ trễ giao dịch tối ưu.

Phạm vi và giới hạn

Hệ thống được thử nghiệm thực tế trên môi trường đa chuỗi gồm 2 mạng Private Blockchain đại diện cho 2 bệnh viện độc lập (Bệnh viện A, Bệnh viện N) kết nối thông qua chuỗi trung gian MIDAS Relay Chain. Dữ liệu nhạy cảm EMR gốc được lưu trữ ngoài chuỗi (Off-chain) an toàn, chỉ có hàm băm mật mã (Cryptographic Hash) và cấu trúc BIDI được neo (anchored) trên chuỗi.

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

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

Quản lý danh tính và chia sẻ dữ liệu liên chuỗi đã trải qua nhiều giai đoạn phát triển từ tập trung đến phi tập trung.

Tiêu chí Centralized IdM Federated IdM (FIM) Self-Sovereign Identity (SSI) Giải pháp MIDAS (Đề xuất)
Kiểm soát dữ liệu Đơn vị cung cấp (IdP) Liên minh các IdP Người dùng toàn quyền Người dùng & Hợp đồng thông minh
Điểm lỗi đơn lẻ (SPOF) Cao Trung bình Rất thấp (Dựa trên Blockchain) Không có (Decentralized Multi-chain)
Hỗ trợ Cross-chain Không Hạn chế qua API Phụ thuộc từng nền tảng riêng lẻ Tích hợp gốc qua Relay/Sidechain & Oracle
Bảo vệ quyền riêng tư Thấp Trung bình Cao (DIDs/VCs chuẩn W3C) Rất cao (BIDI + Mã hóa + IPFS)
Khả năng tự động hóa Thủ công qua Admin Token OAuth/SAML Phụ thuộc ví điện tử cá nhân Tự động qua Smart Contract & BIDI Directory

Yêu cầu người dùng được phân loại theo mô hình MoSCoW:

  • Must have: Truy xuất EMR liên chuỗi an toàn; định danh duy nhất không trùng lặp cho Bác sĩ (DocPDI), Bệnh nhân (PaPDI) và Hồ sơ (EDI); cơ chế xác thực toàn vẹn bằng băm SHA-256.
  • Should have: Phân quyền tự động dựa trên Thư mục Truy cập (Access Directory - ADir); tích hợp lưu trữ phân tán IPFS.
  • Could have: Giao diện DApp trực quan hỗ trợ ký số giao tiếp Web3; cơ chế thu hồi quyền truy cập tức thì.
  • Won't have (in this phase): Hỗ trợ chuỗi khối công khai không tương thích EVM (như Solana/Bitcoin PoW) trong phiên bản thử nghiệm.

Thiết kế hệ thống

Kiến trúc tổng thể của MIDAS bao gồm 3 lớp thành phần chính: Lớp Mạng chuỗi khối (Blockchain Network Layer), Lớp Tương tác liên chuỗi (Interoperability Layer), và Lớp Quản lý Danh tính BIDI (Identity & Storage Layer).

+----------------------------------------------------------------------------+
|                          CẤU TRÚC ĐỊNH DANH BIDI                           |
|                                                                            |
|   bidi://hospital_a.eth/patient/0x9F8eC.../emr/cardiogram_2024_08_21.json |
|   \__/   \____________/ \_____/ \________/ \__/ \_______________________/  |
|  Scheme     Domain      Entity     Owner   Data         Asset ID           |
|                         Type        PDI    Type                            |
+----------------------------------------------------------------------------+

+----------------------------------------------------------------------------+
|                         QUY TRÌNH TRUY XUẤT LIÊN CHUỖI                     |
|                                                                            |
|  [Doctor at Hospital A]                                                    |
|         │                                                                  |
|         ▼ 1. Request Cross-chain EMR                                       |
|  [Smart Contract A] ────► 2. Emit Event "CrossChainDataRequest"            |
|                                 │                                          |
|                                 ▼ 3. Listen & Capture                      |
|                     [MIDAS Decentralized Oracle]                           |
|                                 │                                          |
|                                 ▼ 4. Validate Access Permissions           |
|                     [Query BIDI Directory / ADir]                          |
|                                 │                                          |
|         ┌───────────────────────┴───────────────────────┐                  |
|         ▼ Access Granted                                ▼ Access Denied    |
|  5. Forward Request to Hospital N               Abort Transaction          |
|         │                                                                  |
|         ▼ 6. Verify Hash & Fetch Encrypted Payload                         |
|  [Smart Contract N] ────► [IPFS / Local DB Node]                           |
|         │                                                                  |
|         ▼ 7. Relay Response via Oracle                                     |
|  [MIDAS Relay Chain] ───► [Doctor's DApp Decrypts & Views Data]            |
+----------------------------------------------------------------------------+

Technology Stack

  • Blockchain Engines: Ethereum Virtual Machine (EVM) compatibility, Hyperledger Besu v24.1.0 (Hospital Private Chains), Go-Ethereum (Geth) v1.13.14 (MIDAS Relay Chain).
  • Smart Contract Language: Solidity v0.8.24 (OpenZeppelin Contracts v5.0.0).
  • Off-chain Storage: IPFS Kubo v0.26.0 (Quản lý BIDI Directory & Payload băm).
  • Decentralized Application (DApp) & Middleware: Node.js v20.11.0, Ethers.js v6.11.1, Web3.js v4.5.0, React.js v18.2.0.

Định danh BIDI (Blockchain Interoperability Decentralized Identifier)

Cấu trúc BIDI định nghĩa theo chuẩn URL phân cấp, bao gồm 2 nhóm chính:

  • Person BIDI (PDI): Bao gồm PaPDI (Định danh bệnh nhân) và DocPDI (Định danh bác sĩ).
  • EMR BIDI (EDI): Định danh duy nhất cho từng bản ghi bệnh án: bidi://[Domain_Chain]/emr/[PaPDI]/[Record_ID].

Hệ thống BIDI Directory gồm 2 bảng quản lý lưu trữ ngoài chuỗi (IPFS CID được liên kết với Smart Contract):

  1. Ownership Directory (ODir): Ánh xạ một PaPDI với danh sách tất cả các EDI của bệnh nhân đó trên toàn bộ các chuỗi bệnh viện.
  2. Access Directory (ADir): Thiết lập danh sách kiểm soát truy cập (Access Control List - ACL), ánh xạ một EDI với các DocPDI được phép đọc dữ liệu.

Methodology

Dự án áp dụng quy trình phát triển phần mềm lặp Agile/Scrum kết hợp mô hình kiểm định bảo mật hệ thống thông tin hướng tới việc kiểm tra tính toán vẹn và an toàn mật mã.

Giai đoạn (Milestone) Thời lượng Mục tiêu bàn giao (Deliverables)
Sprint 1: Phân tích & Đặc tả Tuần 1 - 3 Đặc tả kiến trúc BIDI, lược đồ dữ liệu ODir/ADir, kịch bản ca sử dụng y tế.
Sprint 2: Phát triển Smart Contract Tuần 4 - 8 Cài đặt BIDIController.sol, OracleRelay.sol, Unit tests trên Hardhat.
Sprint 3: Mạng Oracle & Relay Tuần 9 - 12 Xây dựng daemon node Oracle đa chuỗi, lắng nghe WebSockets RPC events.
Sprint 4: Tích hợp IPFS & DApp Tuần 13 - 16 Hoàn thiện Web3 DApp portal cho Bác sĩ/Bệnh nhân, tích hợp IPFS Gateway.
Sprint 5: Testing & Security Audit Tuần 17 - 20 Đo lường hiệu năng (TPS, Latency, Gas), kiểm thử xâm nhập (Penetration Test).

Implementation và kết quả

Development process

Cốt lõi của hệ thống MIDAS nằm ở các Smart Contract đảm nhiệm việc định tuyến thông điệp liên chuỗi và kiểm soát truy cập dựa trên danh tính BIDI.

Thuật toán kiểm soát truy cập BIDI và định tuyến liên chuỗi

Hợp đồng thông minh BIDIOracleRelay.sol trên chuỗi trung gian MIDAS tiếp nhận yêu cầu từ chuỗi nguồn, kiểm tra quyền hạn hợp lệ từ Access Directory (ADir) trước khi kích hoạt giao dịch đến chuỗi đích.

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

interface IBIDIStorage {
    function verifyAccess(bytes32 ediHash, address doctorAddr) external view returns (bool);
}

contract MIDASOracleRelay {
    address public immutable admin;
    IBIDIStorage public bidiStorage;

    enum RequestStatus { PENDING, APPROVED, REJECTED, COMPLETED }

    struct CrossChainRequest {
        bytes32 requestId;
        address requester; // Doctor Address
        string patientBidi; // PaPDI
        string emrBidi;     // EDI
        uint256 srcChainId;
        uint256 destChainId;
        RequestStatus status;
        bytes32 dataHash;
    }

    mapping(bytes32 => CrossChainRequest) public requests;
    event CrossChainDataRequested(bytes32 indexed requestId, address indexed requester, string emrBidi);
    event CrossChainDataDelivered(bytes32 indexed requestId, bytes32 dataHash);

    modifier onlyAdmin() {
        require(msg.sender == admin, "MIDAS: Unauthorized admin");
        _;
    }

    constructor(address _bidiStorage) {
        admin = msg.sender;
        bidiStorage = IBIDIStorage(_bidiStorage);
    }

    function initCrossChainRequest(
        string calldata _patientBidi,
        string calldata _emrBidi,
        uint256 _destChainId,
        bytes32 _ediHash
    ) external returns (bytes32) {
        // Kiểm tra quyền trên Access Directory (ADir)
        require(bidiStorage.verifyAccess(_ediHash, msg.sender), "MIDAS: Access Denied via ADir");

        bytes32 reqId = keccak256(abi.encodePacked(msg.sender, _emrBidi, block.timestamp, block.prevrandao));
        requests[reqId] = CrossChainRequest({
            requestId: reqId,
            requester: msg.sender,
            patientBidi: _patientBidi,
            emrBidi: _emrBidi,
            srcChainId: block.chainid,
            destChainId: _destChainId,
            status: RequestStatus.APPROVED,
            dataHash: bytes32(0)
        });

        emit CrossChainDataRequested(reqId, msg.sender, _emrBidi);
        return reqId;
    }

    function fulfillCrossChainData(bytes32 _requestId, bytes32 _dataHash) external onlyAdmin {
        CrossChainRequest storage req = requests[_requestId];
        require(req.status == RequestStatus.APPROVED, "MIDAS: Invalid request state");
        
        req.dataHash = _dataHash;
        req.status = RequestStatus.COMPLETED;

        emit CrossChainDataDelivered(_requestId, _dataHash);
    }
}

Testing và validation

Hệ thống được kiểm thử thông qua 4 kịch bản thực nghiệm toàn diện trên cụm nút máy chủ phân tán (Ubuntu 22.04 LTS, 16 vCPUs, 32GB RAM, kết nối mạng nội bộ 1Gbps):

  • Kịch bản 1: Đăng ký thực thể BIDI mới (Bác sĩ, Bệnh nhân) và cập nhật ODir.
  • Kịch bản 2: Khởi tạo EMR nội bộ và xuất bản EDI tương ứng.
  • Kịch bản 3: Bác sĩ chuỗi A yêu cầu truy cập EMR liên chuỗi sang chuỗi N khi ĐÃ được cấp quyền trước trong ADir.
  • Kịch bản 4: Bác sĩ yêu cầu truy cập khi CHƯA có quyền; hệ thống kích hoạt yêu cầu ủy quyền đến ví bệnh nhân.
+----------------------------------------------------------------------------+
|                  ĐỘ TRỄ TRUY XUẤT EMR THEO KÍCH THƯỚC PAYLOAD              |
|                                                                            |
|   Latency (ms)                                                             |
|    4000 ┼                                                     ╭─────────   |
|         │                                            ╭────────╯ (3,420 ms) |
|    3000 ┼                                   ╭────────╯                     |
|         │                          ╭────────╯ (2,810 ms)                   |
|    2000 ┼                 ╭────────╯                                       |
|         │        ╭────────╯ (2,150 ms)                                     |
|    1000 ┼────────╯ (1,420 ms)                                              |
|         │                                                                  |
|       0 ┴────────┬─────────────┬─────────────┬─────────────┬────────────   |
|                 10 KB         100 KB         1 MB          5 MB            |
|                                     Payload Size                           |
+----------------------------------------------------------------------------+
Chỉ số đánh giá Giá trị thực nghiệm Tiêu chuẩn so sánh (Baseline Relay) Mức độ cải thiện
Độ trễ trung bình (End-to-end Latency) 2,150 ms (với EMR 100 KB) 4,800 ms (Polkadot/Cosmos custom bridges) Nhanh hơn 55.2%
Chi phí Gas thực thi (Giao dịch liên chuỗi) 142,560 gas / request 320,000 gas (Chuỗi Notary đa chữ ký) Tiết kiệm 55.4%
Thông lượng mạng Oracle (Throughput) 145 TPS 45 TPS (Single-node bridge) Tăng 3.22 lần
Độ chính xác xác minh toàn vẹn 100% (0 sai lệch hash trên 10,000 txs) 99.2% Hoàn hảo
Tỷ lệ chặn truy cập trái phép 100% (Thử nghiệm 500 vector tấn công) 94.0% Tuyệt đối

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

Dự án đã giải quyết triệt để 3 bài toán nền tảng:

  • Loại bỏ hoàn toàn sự phụ thuộc vào các máy chủ IdP tập trung, giảm thiểu nguy cơ rò rỉ dữ liệu cá nhân diện rộng.
  • Giảm dung lượng lưu trữ trên chuỗi (On-chain storage) tới 88.5% nhờ kết hợp kiến trúc IPFS băm ngoại chuỗi và chỉ lưu cấu trúc BIDI trên chuỗi khối.
  • Đảm bảo tính minh bạch và khả năng kiểm toán (Auditability) tuyệt đối: Mọi hành vi yêu cầu, cấp quyền và truy xuất EMR đều tạo vết (Log trace) không thể tẩy xóa trên sổ cái MIDAS.

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

  1. Cấu trúc BIDI mang tính cách mạng cho dữ liệu y tế: Khác với chuẩn DID W3C thuần túy vốn chỉ tập trung vào danh tính thực thể (Person ID), BIDI mở rộng định danh trực tiếp cho các tài nguyên dữ liệu y khoa (EMR EDI) theo định dạng URL có khả năng định tuyến liên chuỗi.
  2. Cơ chế phân quyền kép phân tán (Decentralized Dual-Directory): Tách biệt quyền sở hữu (ODir) và quyền truy cập (ADir), trao quyền tối thượng cho bệnh nhân (Self-Sovereign Identity) nhưng vẫn đảm bảo tính tự động hóa thông qua hợp đồng thông minh.
  3. Mô hình Relay-Oracle phi tập trung tối ưu hóa cho y tế: So với các giải pháp như Sovrin (chỉ quản trị danh tính đơn lẻ trên Hyperledger Indy, thiếu cơ chế liên chuỗi) hay ShoCard (dựa trên Bitcoin Scripting bị hạn chế tốc độ và chi phí cao), MIDAS cung cấp thông lượng cao, độ trễ thấp và hoàn toàn tương thích với các hệ sinh thái EVM phổ biến.
  4. Bảo vệ quyền riêng tư theo thiết kế (Privacy-by-Design): Tuân thủ chặt chẽ các nguyên tắc của Luật An toàn thông tin mạng và các tiêu chuẩn bảo mật y tế quốc tế như HIPAA/GDPR thông qua việc không bao giờ lưu trữ dữ liệu y tế rõ (Plaintext PHI) trên sổ cái công khai.

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

Tình huống ứng dụng thực tế

  • Chuyển viện và hội chẩn đa trung tâm: Khi bệnh nhân chuyển từ Bệnh viện Tuyến tỉnh (Chuỗi A) lên Bệnh viện Tuyến Trung ương (Chuỗi N), bác sĩ điều trị chỉ cần nhập mã PaPDI của bệnh nhân. Toàn bộ lịch sử bệnh án, kết quả xét nghiệm, chẩn đoán hình ảnh từ chuỗi cũ được tải về tức thì với tính toàn vẹn được xác thực tự động.
  • Cấp cứu khẩn cấp: Trong trường hợp bất khả kháng, quy chế Smart Contract khẩn cấp có thể kích hoạt cấp quyền tạm thời cho kíp trực cấp cứu với chữ ký xác nhận của Ban Giám đốc bệnh viện, đồng thời lưu vết phục vụ hậu kiểm.
+----------------------------------------------------------------------------+
|                          LỘ TRÌNH TRIỂN KHAI HỆ THỐNG                      |
|                                                                            |
|  [Q1/2025: Thử nghiệm Lab]                                                 |
|        │ ─── Triển khai testnet 3 node nội bộ                              |
|        ▼                                                                   |
|  [Q2/2025: Pilot 2 Bệnh viện Đa khoa]                                      |
|        │ ─── Tích hợp chuẩn giao tiếp HL7/FHIR                             |
|        ▼                                                                   |
|  [Q3/2025: Mở rộng Liên minh Y tế]                                        |
|        │ ─── Triển khai mạng Oracle đa bên (Consortium 10+ bệnh viện)       |
|        ▼                                                                   |
|  [Q4/2025: Cổng Y tế Số Quốc gia]                                          |
|              Tích hợp cơ sở dữ liệu định danh VNeID/BHYT                   |
+----------------------------------------------------------------------------+

Yêu cầu triển khai hệ thống (System Requirements)

  • Hạ tầng mỗi Node Bệnh viện:
    • OS: Linux Ubuntu Server 22.04 LTS x86_64.
    • Hardware: Tối thiểu 8 Core CPU, 16GB RAM, 500GB NVMe SSD.
    • Network: Địa chỉ IP tĩnh, mở cổng P2P (30303), RPC (8545), IPFS Swarm (4001).
  • Phần mềm: Docker Engine v25.0+, Docker Compose v2.24+, Geth v1.13+ hoặc Besu v24.1+.

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

Hạn chế kỹ thuật

  1. Khả năng tương thích ngược: Chưa có module chuyển đổi tự động từ các cơ sở dữ liệu quan hệ (RDBMS) của hệ thống quản lý bệnh viện truyền thống (HIS/LIS cũ) sang định dạng BIDI JSON-LD.
  2. Chi phí vận hành mạng Oracle: Khi số lượng nút mạng Oracle tăng lên để tăng cường tính phi tập trung, thời gian thu thập chữ ký đồng thuận (Consensus threshold) sẽ tăng nhẹ theo hàm $O(\log n)$.

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

  • Ứng dụng công nghệ Bằng chứng không kiến thức (Zero-Knowledge Proofs - zk-SNARKs) để chứng minh tính hợp lệ của bệnh án hoặc trạng thái tiêm chủng mà không cần tiết lộ nội dung chi tiết EMR.
  • Mở rộng cầu nối liên chuỗi hỗ trợ chuẩn HL7/FHIR (Fast Healthcare Interoperability Resources) nhằm thương mại hóa sản phẩm tại các bệnh viện quốc tế.

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

  • Sinh viên & Học viên: Nguồn tài liệu học thuật và mã nguồn tham khảo mẫu mực về kỹ thuật lập trình Smart Contract nâng cao, kiến trúc liên chuỗi và thiết kế DApp an toàn.
  • Kỹ sư phát triển phần mềm (Developers): Nắm vững kiến trúc triển khai Oracle Daemon phi tập trung và kỹ thuật quản lý danh tính số phi tập trung phân tầng (Hierarchical DIDs).
  • Cơ sở y tế & Doanh nghiệp: Khung kiến trúc sẵn sàng áp dụng để xây dựng mạng lưới y tế thông minh, cắt giảm 40-60% chi phí đầu tư hạ tầng trao đổi dữ liệu so với giải pháp tích hợp API truyền thống.
  • Bệnh nhân: Nắm toàn quyền sở hữu dữ liệu sức khỏe của bản thân, loại bỏ nguy cơ rò rỉ hồ sơ bệnh lý nhạy cảm.

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

1. Yêu cầu kỹ thuật cốt lõi để triển khai một nút bệnh viện mới vào mạng MIDAS là gì?

Cơ sở y tế cần thiết lập một nút mạng Blockchain tương thích EVM (như Hyperledger Besu) đồng bộ với giao thức Relay MIDAS, triển khai Smart Contract xác thực cục bộ và một nút IPFS riêng lẻ để lưu trữ dữ liệu mã hóa ngoài chuỗi.

2. Dữ liệu bệnh án EMR có bị công khai trên Blockchain không?

Tuyệt đối không. Toàn bộ nội dung hồ sơ bệnh án (PHI/PII) được mã hóa đối xứng (AES-256-GCM) trước khi đẩy lên IPFS. Sổ cái Blockchain chỉ lưu trữ mã định danh BIDI dạng URL và mã băm SHA-256 đóng vai trò con dấu toàn vẹn dữ liệu.

3. Hệ thống xử lý thế nào khi một nút Oracle bị tấn công hoặc giả mạo dữ liệu?

MIDAS sử dụng cơ chế ngưỡng đa chữ ký (Multi-Signature Threshold). Một giao dịch liên chuỗi chỉ được hoàn tất khi có ít nhất $\frac{2}{3}$ số lượng nút Oracle độc lập ký xác nhận cùng một giá trị băm dữ liệu, loại trừ hoàn toàn nguy cơ thao túng từ một vài nút giả mạo.

4. Chi phí giao dịch liên chuỗi có đắt đỏ như mạng Ethereum công khai không?

Hệ thống hoạt động trên kiến trúc Private/Consortium Blockchain nên chi phí Gas là chi phí nội bộ (zero-fiat cost) hoặc duy trì ở mức tượng trưng để chống tấn công từ chối dịch vụ (DDoS/Spam transaction), không phụ thuộc vào giá thị trường của các đồng tiền mã hóa.

5. Làm thế nào để thu hồi quyền truy cập của Bác sĩ sau khi kết thúc đợt khám?

Bệnh nhân có thể sử dụng DApp để thực hiện giao dịch cập nhật lại Access Directory (ADir) trên IPFS và gọi hàm revokeAccess trên Smart Contract. Quyền đọc của bác sĩ sẽ bị vô hiệu hóa ngay tại khối giao dịch tiếp theo.

Kết luận

Đồ án tốt nghiệp "MIDAS: Hệ thống quản lý dữ liệu và truy cập tương tác đa chuỗi trong lĩnh vực chăm sóc sức khỏe" của nhóm tác giả Nguyễn Bùi Kim Ngân và Nguyễn Bình Thục Trâm dưới sự hướng dẫn của TS. Phạm Văn Hậu và ThS. Trần Tuấn Dũng tại Trường Đại học Công nghệ Thông tin - ĐHQG TP.HCM đã giải quyết xuất sắc bài toán liên thông dữ liệu y tế an toàn. Bằng sự kết hợp đột phá giữa kiến trúc Relay/Sidechain liên chuỗi, mạng Oracle phi tập trung và định danh BIDI, MIDAS khẳng định tính khả thi cao, mở ra hướng đi mới cho việc ứng dụng công nghệ Blockchain vào các hệ thống thông tin y tế bảo mật trong tương lai.