전자 의료 기록 공유 상호 운용성 가이드

개인정보보호위원회(PIPC)의 2024년 보고서는 전자 의료 기록 침해의 29%가 시스템 간 이관 과정에서 발생했음을 밝혔다. 개인정보 보호법(PIPA) 제29조와 의료법은 전자 의료 기록 공유 시 암호화와 접근 통제를 의무화한다. 시스템 간 전자 의료 기록 공유는 최소 네 가지 표준의 조화를 필요로 한다: API 기반 교환을 위한 HL7 FHIR R4, 문서 기반 전송을 위한 C-CDA R2.1, 레거시 메시지를 위한 HL7 v2.x, 그리고 영상을 위한 DICOM. USCDI v3는 미국 의료 제공자가 공유 가능하게 해야 하는 최소 데이터 세트를 정의하고, TEFCA는 적격 건강 정보 네트워크(QHIN)를 통한 거버넌스 레이어를 확립한다.

실제로 작업하는 표준 스택

건강 기록 상호운용성이 표준의 혼합처럼 보이는 이유는 실제로 그러하기 때문이다. 각 레이어가 하는 일:

HL7 v2.x: 1990년대의 파이프 구분 메시지. 병원 내부의 검사 처방, ADT(입원/퇴원/이송) 피드, 처방 관리에 여전히 주력. 조직 간 공유에는 부적합.
C-CDA R2.1: 환자 요약서, 퇴원 요약서, 또는 의뢰서를 나타내는 구조화된 XML 문서. Direct 메시지와 대부분의 HIE 교환의 근간.
HL7 FHIR R4: JSON 또는 XML로 HTTPS를 통해 교환되는 RESTful 리소스(Patient, Observation, Condition, MedicationRequest). 인증 EHR에 대한 ONC Cures Act 규칙에서 요구하는 현대 레이어.
DICOM: 영상 표준. 자체 파이프(DIMSE, DICOMweb)를 통해 이동.
USCDI v3: 모든 인증 EHR이 노출해야 하는 필수 데이터 클래스 및 요소(임상 기록, 사회적 결정 요인, 성적 지향/성 정체성 포함).

"EHR을 공유"할 때 실제로는 각 레이어에서 단편들을 수신자에게 맞는 올바른 형식으로 엮어 공유하는 것이다.

FHIR API와 정보 차단 규칙

ONC의 21세기 치료법 최종 규칙(45 CFR Part 171)은 2020년 5월부터 정보 차단을 금지된 관행으로 규정하며, 2023년 HHS 최종 규칙 하에서 특정 행위자에 대해 위반당 최대 $100만의 민사 금전 제재를 부과한다. 기술 요건: 인증된 EHR 기술은 USCDI 데이터 세트를 지원하는 FHIR R4 API를 노출해야 한다.

Epic, Cerner, athenahealth, eClinicalWorks와 통합하는 개발자의 경우:

벤더의 개발자 포털에서 앱 등록(Epic on FHIR, Cerner Code, athenahealth Developer Portal)
PKCE를 사용한 OAuth 2.0으로 SMART on FHIR 실행 시퀀스 사용
patient/*.read 또는 특정 리소스와 같은 스코프 요청
HTTPS에서 JSON 번들 수신

실용적인 함정: API 스코프, 속도 제한, 운영 접근은 벤더마다 크게 다르다. Epic의 운영 접근은 서명된 지불자-의료기관 또는 전문 앱 계약이 필요하다.

C-CDA: 여전히 조직 간 요약의 기본

FHIR의 부상에도 불구하고 대부분의 조직 간 기록 교환은 여전히 C-CDA 문서를 통해 이루어진다. C-CDA R2.1 하의 진료 연속성 문서(CCD)는 일반적으로 인간 가독성을 위한 HTML이 내장된 200KB~2MB의 XML이다. 주요 템플릿:

CCD(진료 연속성 문서)
퇴원 요약서
의뢰서
협진 기록
경과 기록

이것들은 Direct 메시지(SMTP를 통한 S/MIME) 또는 쿼리 기반 HIE 교환을 통해 흐른다. 수신 EHR은 XML을 파싱하여 구조화된 요소를 로컬 기록에 수집한다. 파싱 품질은 다양하다—일부 EHR은 문제 목록을 깔끔하게 수집하지만 사회력을 누락한다.

TEFCA, QHIN, 국가 네트워크 전략

신뢰 교환 프레임워크 및 공통 협약(TEFCA)은 ONC가 2022년 1월에 완료하고 2023년부터 운영된 네트워크의 네트워크를 만든다. eHealth Exchange, Epic의 Carequality 브리지, Health Gorilla 같은 QHIN은 공통 협약을 통해 서로 연결된다.

전송 임상의 관점에서 TEFCA는 의미한다: 한 번 쿼리하면 치료, 지불, 의료 운영, 공중 보건, 정부 혜택 결정, 개인 접근 서비스, 보장 용도에 대해 QHIN 전반의 참가자에게 도달한다.

API가 실패하고 파일 전송이 필요할 때

모든 표준에도 불구하고 임상의는 어떤 API에도 맞지 않는 파일을 이동해야 하는 경우가 정기적으로 있다.

클리닉이 전자화되기 전의 스캔된 종이 기록 300MB PDF 번들
후향적 검토를 위한 SAS 또는 Stata 형식의 연구 데이터셋
이미지 서버를 복잡하게 할 필요가 없는 가정 건강 상처 사진 세트
계류 중인 의료 과실 사건에 대한 법적 보관 기록

이를 위해 암호화된 파일 전송으로 폴백한다. 요건: HIPAA 준수(BAA 체결), 저장 중 AES-256-GCM 암호화, 전송 중 TLS 1.3, 감사 로깅, 링크 만료. HexaTransfer는 업로드 전 클라이언트 측 암호화로 임시 경로를 제공한다. 전송을 표준 감사 기록에 로깅하여 나중에 설명할 수 있도록 한다.

환자 매칭과 신원 문제

기록을 공유하려면 올바른 환자인지 알아야 한다. 미국에는 국가 환자 식별자가 없어(1998년부터 매년 갱신되는 세출 법안 조항으로 인해) 신원 확인은 이름, 생년월일, 성별, 주소, 전화번호의 확률적 매칭에 의존한다. Sequoia 프로젝트의 환자 매칭 프레임워크는 조직 간 매칭에 최소 7개의 인구 통계 속성을 권장한다.

파일 수준 전송에서는 항상 파일명 또는 표지에 환자 식별자를 포함시킨다—MRN, 생년월일, 최소 하나의 추가 식별자. 임상의가 "Jane-S-MRI.dcm"이 어느 환자 것인지 알 것이라고 의존하지 말라.

동의, 분할, 42 CFR Part 2

모든 기록이 동등하게 공유되지는 않는다. 42 CFR Part 2는 연방 지원 프로그램의 약물 남용 장애 기록 공유를 일반 HIPAA 승인보다 높은 동의 요건으로 제한한다. 2024년 SAMHSA 규칙이 Part 2를 HIPAA와 더 밀접하게 조정했지만 기록에는 여전히 재공개 금지 통지가 필요하다.

행동 건강, HIV, 유전, 생식 건강 기록에는 종종 주별 공유 규칙이 있다. 전송 도구가 분할을 존중할 수 없다면—문서의 어느 부분에 추가 동의가 필요한지 표시할 수 없다면—정신 건강 기록에 사용하지 말라.

공개 회계 및 감사

HIPAA의 공개 회계(45 CFR 164.528)는 환자에게 지난 6년 동안 이루어진 공개 목록에 대한 권리를 부여한다. 전송 시스템의 감사 로그가 이 회계를 제공한다.

캡처 사항:

UTC 타임스탬프
발신자 및 수신자 조직
목적 코드(TREATMENT, PAYMENT, OPERATIONS, AUTHORIZATION 등)
전송된 데이터 범주
환자 ID

"사용자 X가 파일 Y를 업로드했다"만 로깅하는 일반 파일 공유 도구에 의존하면 환자가 회계를 요청할 때 곤란해진다.

소규모 의료 기관과 자원 격차

3명의 1차 진료 의사로 구성된 의원에는 CIO가 없다. 청구와 함께 IT를 처리하는 사무 관리자가 있다. 그들도 여전히 수요 시 USCDI 준수 기록을 제공하고, 모든 벤더와 BAA를 체결하고, 정보 차단 민원을 처리해야 한다. 실용적인 접근:

Direct, FHIR, 환자 API가 기본 제공되는 EHR(athenahealth, Elation, DrChrono) 사용
EHR이 보낼 수 없는 모든 것을 위한 BAA가 있는 임시 암호화 전송 도구 하나 선택(HexaTransfer 등)
1페이지 SOP에 워크플로우 문서화
매주 사용할 두 가지 도구에 대해 모든 직원 교육

전자 의료 기록 공유는 단일 벤더가 해결할 문제가 아니다. 유지 관리할 레이어드 워크플로우다. 가능한 곳에서 표준을 올바르게 적용하고, 표준이 적용되지 않는 케이스를 위한 깔끔한 암호화된 폴백을 갖추라.

https://hexatransfer.com — 무료, 계정 불필요, 최대 10 GB.