블록체인 기반 EHR 관리와 환자 동의 데이터 공유

EHR 공유에서 남는 문제는 데이터보다 신뢰다

진료기록, 처방, 검사결과, 영상 데이터처럼 환자 진료와 관련된 구조화·비구조화 데이터는 기관별 사일로에 묶이기 쉽다. 데이터 이동성이 제한된 환경에서는 기관 간 조회와 협진 과정도 복잡해진다.

블록체인은 이 문제에서 의료 원본을 저장하는 저장소라기보다, 변경불가 감사 추적과 탈중앙 합의 기반의 신뢰 공유를 위한 계층으로 쓸 수 있다. 데이터 무결성을 확인할 해시 기준점을 제공하고, 실제 의료 원본 데이터는 오프체인에 보관하는 방식이 전제다.

온체인에는 접근 동의(consent), 접근 제어 정책, 데이터 해시·포인터, 이벤트 로그를 둔다. EHR 원본은 HIS/PACS, 데이터 레이크, FHIR 서버, IPFS/S3 등의 오프체인 저장소에 보관하며, 암호화·키 관리와 접근 토큰 발급도 이 계층에서 처리한다. 온체인 이벤트를 기준으로 오프체인 오케스트레이션을 연동한다.

동의와 접근 이력을 체인에서 다루는 방식

DID(Decentralized Identifier)와 VC(Verifiable Credential)는 환자와 의료기관의 신원을 검증하고 권한을 위임하는 데 사용할 수 있다. 동의 관리 스마트 컨트랙트는 권한 부여, 철회, 만료를 트랜잭션으로 남겨 기관 간 상태를 일관되게 유지한다.

데이터 설계에서는 포인터와 메타데이터를 온체인에 두고 원본은 오프체인에 둔다. 해시(anchor)는 원본의 무결성을 검증하는 기준이 된다. 데이터 암호화 키는 KMS/HSM에 보관하고, 체인에는 키 레퍼런스만 유지하는 식으로 암호화 계층을 분리한다.

접근 통제는 DID/VC 기반 상호 인증에 ABAC/RBAC 혼합 정책을 적용해 리소스 수준까지 내릴 수 있다. 접근 요청, 승인, 거부는 모두 온체인 이벤트로 기록해 변경불가 감사 추적을 확보한다.

프라이버시 측면에서는 최소 데이터 원칙, 가명화·익명화, 선택적 공개 범위 설정이 필요하다. ZKP/TEE를 이용해 민감 정보 노출을 줄일 수 있으며, GDPR/CCPA/국내 개인정보보호법 등의 준수도 고려해야 한다. 삭제 청구에는 오프체인 삭제와 암호키 파기(crypto-shredding)를 조합한다.

의료 환경의 합의 계층으로는 퍼미션드 BFT/PoA를 선택해 수백~수천 TPS와 짧은 확정성을 목표로 할 수 있다. 읽기 부하는 캐시와 인덱스 노드로 분산하고, 오프체인 토큰 발급과 감사 로깅은 이벤트 기반 비동기 처리로 지연을 줄인다.

운영 주체가 여러 기관이라면 컨소시엄 거버넌스가 필요하다. 정책 변경 프로포절과 다중서명 승인 절차를 마련하고, 키 로테이션, 체인코드 버전 관리, 재현 가능한 배포, 운영 감사 자동화를 운영 기준으로 둔다. 규제 갱신은 최신 정보 확인이 필요하다.

의료 데이터 흐름에 적용할 수 있는 장면

환자 동의를 기준으로 타병원의 기록을 조회할 때 FHIR API와 온체인 동의 레퍼런스를 연결할 수 있다. 이는 중복 검사를 줄이고 전원·협진의 효율을 높이는 흐름이다.

임상시험과 실사용데이터(RWD)에서는 프로토콜 준수, 타임스탬프, 데이터 변경 이력을 온체인에 앵커링할 수 있다. 규제기관 제출용 감사 패키지 자동 생성에도 연결된다.

보험 청구와 심사에는 동의 검증, 서류 무결성 확인, 자동 룰 평가를 잇는 파이프라인을 구성할 수 있다. 허위 청구 탐지 정확도 개선과 심사 리드타임 단축이 목적이다.

원격의료와 웨어러블 데이터 공유에서는 디바이스 데이터의 해시를 고정하고, 목적을 세분화한 동의 정책을 적용한다. 동적 만료와 철회를 지원하면 환자의 데이터 통제권을 강화할 수 있다.

성과 목표와 체인 구조의 선택

이 구조에서는 데이터 교차 조회 시간 5080% 단축, 재검사율 1020% 감소를 가정한다. 허위 청구 손실은 15% 이상 감소 가능하며, 동의 감사 비용은 30% 절감할 수 있다. 퍼미션드 BFT 환경에서는 1,0003,000 TPS와 확정성 13초 수준을 목표로 설정한다.

정성적으로는 환자 주권과 신뢰를 높이고, 기관 간 상호운용성을 개선할 수 있다. 변경불가 감사 기록은 규제 대응을 쉽게 만들며 데이터 윤리 준수 문화를 강화한다.

유형	성능(TPS)	확장성(노드/참여)	일관성/최종성	안정성/신뢰	운영 편의
퍼블릭	중	매우 높음	확률적 최종성, 느림	매우 높음	낮음
퍼미션드	높음	중	결정적 최종성, 빠름	높음	높음
컨소시엄	높음	중~높음	결정적 최종성, 중~빠름	높음	중~높음

공공 검증과 성능·프라이버시 사이에는 트레이드오프가 있다. 규제 준수와 데이터 주권 요구가 강한 의료 환경에서는 퍼미션드 또는 컨소시엄 체인을 우선 검토할 수 있다.

동의 검증부터 감사 기록까지의 요청 경로

⤢✕

이 흐름의 입력은 환자 동의, 제공자 요청, 오프체인 저장소의 데이터다. 온체인에서 동의를 확인한 뒤 포인터를 얻고, 오프체인 데이터를 가져와 해시를 검증한 후 접근 로그를 남긴다. 성공하면 데이터를 제공하고, 실패하면 무결성 경보와 접근 차단으로 이어진다.

온체인 상태가 확정된 뒤 오프체인 토큰을 발급하고, 이벤트 구독 오케스트레이션으로 원자적 처리와 유사한 흐름을 보장한다. 재시도와 멱등 키도 적용한다. 만료·철회, 해시 불일치, 토큰 만료, 네트워크 타임아웃은 각각 분기 처리 대상이다.

동의 레지스트리 스마트 컨트랙트

환경은 Solidity ^0.8.20과 EVM 호환 퍼미션드 체인(Geth/Quorum, Besu 등)을 가정하며, OpenZeppelin 라이브러리는 선택사항이다. 아래 코드는 단순 참조용 예시다. 실제 서비스에서는 DID/VC 검증, 세분화된 스코프, 강화된 감사가 필요하다.

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

contract ConsentRegistry {
    struct Consent {
        address patient;
        address grantee;
        bytes32 resourceId;   // 예: FHIR Resource 식별자 해시
        bytes32 scope;        // 예: read|write|research 등 해시
        uint64  expiry;       // UNIX time
        bool    active;
    }

    mapping(bytes32 => Consent) private consents; // key: keccak(patient, grantee, resourceId, scope)
    event ConsentGranted(bytes32 indexed key, address patient, address grantee, bytes32 resourceId, bytes32 scope, uint64 expiry);
    event ConsentRevoked(bytes32 indexed key, address patient, address grantee);
    event AccessLogged(bytes32 indexed key, address accessor, bytes32 purpose);
    event IntegrityAlert(bytes32 indexed key, bytes32 detail);

    function _key(address patient, address grantee, bytes32 resourceId, bytes32 scope) internal pure returns (bytes32) {
        return keccak256(abi.encodePacked(patient, grantee, resourceId, scope));
    }

    function grantConsent(address grantee, bytes32 resourceId, bytes32 scope, uint64 expiry) external {
        require(expiry > block.timestamp, "invalid expiry");
        bytes32 key = _key(msg.sender, grantee, resourceId, scope);
        consents[key] = Consent(msg.sender, grantee, resourceId, scope, expiry, true);
        emit ConsentGranted(key, msg.sender, grantee, resourceId, scope, expiry);
    }

    function revokeConsent(address grantee, bytes32 resourceId, bytes32 scope) external {
        bytes32 key = _key(msg.sender, grantee, resourceId, scope);
        Consent storage c = consents[key];
        require(c.patient == msg.sender && c.active, "no active consent");
        c.active = false;
        emit ConsentRevoked(key, msg.sender, grantee);
    }

    function hasConsent(address patient, address grantee, bytes32 resourceId, bytes32 scope) external view returns (bool ok, uint64 expiry) {
        bytes32 key = _key(patient, grantee, resourceId, scope);
        Consent memory c = consents[key];
        ok = c.active && c.expiry > block.timestamp;
        expiry = c.expiry;
    }

    // 감사용 로그 훅(오프체인 오케스트라에서 호출)
    function logAccess(address patient, address accessor, bytes32 resourceId, bytes32 scope, bytes32 purpose) external {
        bytes32 key = _key(patient, accessor, resourceId, scope);
        require(consents[key].active && consents[key].expiry > block.timestamp, "no consent");
        emit AccessLogged(key, accessor, purpose);
    }

    function reportIntegrityFailure(address patient, address accessor, bytes32 resourceId, bytes32 scope, bytes32 detail) external {
        bytes32 key = _key(patient, accessor, resourceId, scope);
        emit IntegrityAlert(key, detail);
    }
}

키 관리는 HSM/MPC로 환자·기관 키를 보호하고, 분실 대응을 위해 소셜 리커버리와 계정 추상화를 도입하는 방향을 검토한다. 온체인 식별자와 스코프에는 해시화·솔트를 적용하며, 메타데이터 재식별 위험도 평가한다. 최소 권한, 데이터 수명주기 관리, 접근 로그 보존 정책을 명시하고 규정 변경에 맞춘 정책 업데이트 프로세스를 확보해야 한다.

파일럿에서 운영 체계로 확장하기

파일럿에서는 단일 지역 컨소시엄 체인에 동의 관리와 오프체인 FHIR 서버 연동을 붙이고, 1~2개 사용 사례를 검증한다. 이후 기관을 추가하고 DID/VC를 통합하며, 자동화된 감사 리포트와 성능 튜닝(BFT 피어 확장, 인덱스 노드)을 적용한다.

운영 단계에서는 다지역 DR, 키 로테이션·비상철회, 데이터 레이크·분석 파이프라인 연계를 구성한다. ZKP 기반 질의 검증 PoC도 이 단계에서 검토 대상이 된다.

블록체인은 EHR 데이터의 신뢰 공유, 변경불가 감사, 동의 중심 접근 제어를 통해 기관 간 데이터 공유와 환자 프라이버시를 함께 다루는 기반이 될 수 있다. 퍼미션드·컨소시엄 아키텍처, 온·오프체인 분리, DID/VC, 키 관리와 거버넌스를 결합해 단계적으로 도입하며 규제 변화와 프라이버시 기술 발전을 지속적으로 검토한다.