간단한 답변: CDA는 하나의 환자에 대한 하나의 시점에 대한 서명된 XML 파일로, 사람이 읽을 수 있는 서술 부분과 컴퓨터가 읽을 수 있는 항목을 포함하며, 전체가 변경되지 않고 유지되어야 합니다. FHIR은 환자(Patient), 마흔 개의 관찰(Observation), 세 개의 상태(Condition)와 같이 각각 고유한 URL을 가진 리소스들을 제공하며, REST API를 통해 독립적으로 가져오고, 검색하고, 업데이트할 수 있습니다. FHIR은 또한 리소스들을 문서(Composition으로 시작하는 document 타입의 Bundle)로 묶을 수 있으며, 이는 CDA와 직접적으로 동일합니다. 규정이나 파트너가 CDA를 요구하는 경우 CDA를 선택하고, API, 앱 및 쿼리해야 하는 모든 것에 대해서는 FHIR을 선택하십시오.
두 가지 형태
CDA와 FHIR는 두 가지 다른 형태를 가집니다. CDA는 OID로 식별되는 HL7 v3 데이터 유형을 기반으로 구축된 전체 XML 문서를 교환하며, 필수적인 서술, 쿼리 불가, 업데이트 불가, 전체 문서 서명이 특징입니다. FHIR는 칸노니컬 URL로 식별되는 개별 JSON 또는 XML 리소스 또는 번들을 교환하며, 내장된 REST 쿼리, 버전별 업데이트, 구현 가이드에 게시된 프로필을 제공합니다.
| CDA / C-CDA | FHIR | |
|---|---|---|
| 교환 단위 | 전체 문서 | 리소스 또는 리소스 번들 |
| 형식 | XML, HL7 v3 데이터 타입 | JSON 또는 XML, FHIR 데이터 타입 |
| 식별 | 템플릿 및 코드 시스템에 대한 OID | 프로파일 및 코드 시스템에 대한 URL (표준) |
| 사람이 읽을 수 있는 부분 | 모든 섹션에 필수 <text> |
리소스당 선택적 text.div 서술; 문서에는 필수 |
| 전송 | 정의되지 않음; XDS, Direct, MLLP, 이메일로 전달 | 표준에서 정의된 HTTPS를 통한 REST; 메시징 및 문서도 가능 |
| 쿼리 | 문서 내에서는 불가능; 헤더를 인덱싱하는 레지스트리 | 내장됨: GET /Observation?patient=…&code=… |
| 업데이트 | 불가능; 새 문서가 이전 문서를 대체 | 리소스는 버전 관리되며 제자리에서 업데이트됨 |
| 서명 | 전체 문서, XML-DSig | 전체 번들 가능; 개별 리소스는 거의 서명되지 않음 |
| 프로파일 | 섹션 및 항목별 템플릿 (templateId) | 구현 가이드에 게시된 리소스별 StructureDefinition 프로파일 |
| 용어 | LOINC 섹션 코드, SNOMED/ICD/RxNorm 항목 | 동일한 코드 시스템, CodeableConcept으로 |
차이가 실제 의미하는 것
실제로 CDA와 FHIR의 차이점은 CDA는 서명된 퇴원 요약과 같이 한 번 작성되어 전체적으로 보존되는 콘텐츠에 적합한 반면, FHIR는 혈압 기록과 같이 성장하고 쿼리되는 데이터에 적합하다는 것입니다. CDA 수신자는 표시할 수는 있지만 가져오려면 조정해야 합니다. FHIR 수신자는 자체 레코드와 유사한 형태로 이미 구성된 리소스를 받습니다.
퇴원 요약은 본질적으로 문서입니다. 한 번 작성되고, 한 명의 의사가 서명하며, 몇 년 후에도 정확히 읽었던 대로 재현 가능해야 합니다. 혈압 시리즈는 본질적으로 리소스 집합입니다. 매일 증가하고, 플롯팅되고 필터링되며, 아무도 서명하지 않습니다. CDA는 첫 번째를 잘 처리하고 두 번째는 서투르게 처리합니다 (새로운 측정값마다 전체 문서를 다시 보내야 할 것입니다). FHIR은 두 번째를 네이티브로 처리하고 첫 번째는 문서 메커니즘을 통해 처리합니다.
또 다른 실질적인 차이는 수신자가 할 수 있는 것입니다. CDA 수신자는 항상 문서를 표시할 수 있습니다. 항목을 가져오려면 섹션별로 조정이 필요합니다. FHIR 수신자는 자신의 기록 형태와 동일한 리소스를 받습니다. 어려운 질문은 신원 확인 (이것이 동일한 환자인가?) 및 출처 (누가 언제 이것을 주장했는가?)로 넘어갑니다. 환자 일치를 참조하십시오.
FHIR 문서: 만나는 지점
FHIR 문서는 type: "document"인 Bundle이며, 첫 번째 항목은 Composition입니다. Composition은 CDA 헤더 및 섹션 목록의 역할을 합니다. 유형 (LOINC), 날짜, 작성자, 주제, 관리자, 상태 및 제목, 코드, 서술 텍스트 및 데이터를 담고 있는 리소스에 대한 참조를 포함하는 section[]입니다.
{
"resourceType": "Bundle",
"type": "document",
"identifier": {"system": "urn:ietf:rfc:3986", "value": "urn:uuid:3f2d7a3e-…"},
"timestamp": "2026-03-14T10:15:00+01:00",
"entry": [
{"fullUrl": "urn:uuid:comp-1", "resource": {
"resourceType": "Composition", "status": "final",
"type": {"coding": [{"system": "http://loinc.org", "code": "60591-5", "display": "Patient summary Document"}]},
"subject": {"reference": "urn:uuid:pat-1"},
"date": "2026-03-14T10:15:00+01:00",
"author": [{"reference": "urn:uuid:prac-1"}],
"title": "Patient summary",
"section": [{
"title": "Allergies and intolerances",
"code": {"coding": [{"system": "http://loinc.org", "code": "48765-2"}]},
"text": {"status": "generated", "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p>Penicillin: rash</p></div>"},
"entry": [{"reference": "urn:uuid:allergy-1"}]
}]
}},
{"fullUrl": "urn:uuid:pat-1", "resource": {"resourceType": "Patient", "id": "pat-1"}},
{"fullUrl": "urn:uuid:prac-1", "resource": {"resourceType": "Practitioner", "id": "prac-1"}},
{"fullUrl": "urn:uuid:allergy-1", "resource": {"resourceType": "AllergyIntolerance", "id": "allergy-1", "patient": {"reference": "urn:uuid:pat-1"}, "code": {"coding": [{"system": "http://snomed.info/sct", "code": "764146007", "display": "Penicillin"}]}}}
]
}
국제 환자 요약은 정확히 이것입니다. CDA 트윈이 여전히 필요한 시스템을 위한 CDA 트윈과 함께 FHIR 문서 프로파일입니다. FHIR Bundle 설명도 참조하십시오.
변환 방법
CDA와 FHIR 간의 변환은 제한적이지만 양방향으로 작동합니다. FHIR 구현 가이드의 HL7 C-CDA는 문서 유형, 섹션 및 항목을 컴포지션 프로필 및 리소스에 매핑합니다. 서술 전용 섹션은 데이터 없이 텍스트가 됩니다. FHIR에서 CDA로의 변환은 C-CDA 템플릿에 맞는 리소스에 대해 작동합니다. 어느 방향으로든 원본은 Provenance가 있는 DocumentReference로 유지되어야 합니다.
- CDA → FHIR: HL7 C-CDA on FHIR 구현 가이드는 미국 문서 유형 및 섹션을 Composition 프로파일에 매핑합니다. 항목은 리소스에 매핑됩니다 (Problem Concern Act → Condition, Medication Activity → MedicationStatement, Result Observation → Observation). 이 매핑은 잘 템플릿화된 레벨 3 콘텐츠에 대해서는 결정론적이며, 데이터 없는 텍스트가 되는 서술 전용 섹션에 대해서는 손실이 발생합니다.
- FHIR → CDA: C-CDA 템플릿에 맞는 리소스를 가진 문서의 경우 가능합니다. 문서로 의도되지 않은 자유 형식 FHIR 리소스 (웨어러블 관찰 스트림)는 의미 있는 CDA가 되지 않습니다.
- 원본을 유지하십시오. 어느 방향으로 변환하든, 받은 그대로의 소스를 DocumentReference로 저장하고, 변환된 리소스에서 해당 소스를 가리키도록 Provenance를 사용하십시오. 변환은 보기이며, 대체가 아닙니다.
CDA가 여전히 올바른 답변인 경우
수신 측에서 요구하는 경우(미국 전환 진료, MyHealth@EU 환자 요약 및 전자 처방전, 여러 국가 문서 레지스트리), 콘텐츠가 법적으로 서명 및 전체 보존이 필요한 문서인 경우, 또는 파트너의 인프라가 리소스 대신 문서를 인덱싱하는 IHE XDS인 경우 CDA가 여전히 올바른 답변입니다. 그렇지 않은 경우에는 FHIR로 시작하십시오.
수신 측에서 요구하는 경우 (미국 전환 진료, MyHealth@EU 환자 요약 및 전자 처방전 현재, 여러 국가 문서 레지스트리); 콘텐츠가 법적으로 서명되고 전체적으로 보존되어야 하는 문서인 경우; 파트너의 인프라가 문서를 인덱싱하고 리소스를 인덱싱하지 않는 IHE XDS인 경우. 다른 모든 경우에는 FHIR로 시작하고 문서가 필요한 경우 FHIR 문서를 생성하십시오.
관련 페이지
- CDA 및 C-CDA 설명
- FHIR Bundle 설명
- 국제 환자 요약
- HL7 대 FHIR
- DocumentReference 대 DiagnosticReport 대 Binary
- 환자 일치
출처
- HL7 FHIR R4: 문서
- HL7 FHIR R4: Composition
- HL7 C-CDA on FHIR 구현 가이드
- HL7 FHIR: CDA와의 비교 (부록)
- HL7 국제 환자 요약 IG
자주 묻는 질문
FHIR 문서는 그냥 JSON 형식의 CDA인가요?
아닙니다. 원칙 (전체, 서명됨, 사람이 읽을 수 있음, 헤더 포함)을 공유하지만, 콘텐츠는 일반 FHIR 리소스이므로 동일한 Observation이 문서에 존재하고 API에서 제공될 수 있습니다. CDA에서는 항목이 문서 내에만 존재합니다.
FHIR 문서를 서명할 수 있나요?
예. Bundle.signature는 번들에 대한 디지털 서명을 보유하며, IPS 및 국가 가이드에서 방법을 설명합니다. 실제로는 많은 배포에서 서명보다는 전송 보안 및 출처에 의존합니다.
FHIR에는 templateId가 있나요?
해당하는 것은 meta.profile이며, 리소스가 준수한다고 주장하는 StructureDefinition의 표준 URL 목록입니다. 검증기는 CDA 스키마트론이 템플릿을 확인하는 방식으로 준수 여부를 확인합니다.
새로운 국가 프로그램은 무엇을 선택해야 할까요?
최근 프로그램 (EHDS 교환 형식, 미국 환자 접근 규칙, IPS)은 요약 및 서신에 대해 FHIR 문서와 함께 FHIR을 선택하고, 레거시 파트너를 위해서만 CDA 경로를 유지합니다.
샌드박스에서 무료로 사용해 보세요
5분 만에 첫 FHIR 호출. 환자의 동의가 내장된 HL7 FHIR R4 API: 샌드박스에서 먼저 사용해보고, 자체 앱 또는 병원 시스템을 연결하세요.
무료 · 합성 환자 30명 · 카드 불필요

