간단한 답변: 건강 데이터는 네 가지 표준 계층을 통해 이동합니다. 교환 표준은 시스템 간에 데이터를 전달합니다: 이미지의 경우 HL7 v2 메시지, CDA 문서, FHIR 리소스 및 DICOM. 모델링 및 저장 표준은 시스템 내에서 레코드가 어떻게 구성되는지를 설명합니다: 임상 기록의 경우 openEHR, 연구 데이터베이스의 경우 OMOP. 용어는 양측이 이해할 수 있도록 모든 개념에 코드를 부여합니다: SNOMED CT, LOINC, ICD, ATC, UCUM, RxNorm. 신원 및 보안 표준은 누가 무엇을 읽을 수 있는지 결정합니다: OAuth 2.0 및 SMART on FHIR, 그리고 이 모든 것을 테스트된 레시피로 결합하는 IHE 프로파일. 아무도 하나만 사용하지 않습니다. 병원은 일반적으로 네 가지 계층을 동시에 운영합니다.
지도
의료 상호 운용성 표준은 네 가지 계층으로 구성됩니다. 교환 표준(HL7 v2, CDA, FHIR, DICOM 및 DICOMweb)은 시스템 간에 데이터를 이동시키고, IHE 프로파일은 이를 테스트된 레시피로 결합합니다. openEHR은 저장된 기록을 구조화하고 OMOP는 연구 데이터베이스를 구조화합니다. SNOMED CT 및 LOINC와 같은 용어집과 SMART on FHIR와 같은 ID 표준은 이 모든 것 안에서 사용됩니다.
| 계층 | 표준 | 무엇인가 | 2026년에 어디에서 만날 수 있나요 |
|---|---|---|---|
| 교환 | HL7 v2 | MLLP를 통한 파이프 구분 메시지(ADT, ORU, ORM, SIU) | 병원 내부: 입원, 검사 결과, 주문, 예약. 여전히 가장 일반적인 인터페이스 |
| 교환 | CDA / C-CDA | 사람이 읽을 수 있는 부분과 코딩된 항목이 있는 XML 임상 문서 | 퇴원 요약, 의뢰서, 미국 C-CDA, MyHealth@EU의 국경 간 요약 |
| 교환 | FHIR (R4, R4B, R5) | REST 및 JSON을 통한 웹 리소스(Patient, Observation, Condition…) | 환자 앱, 국가 API, EHR API, US Core, IPS, EHDS 교환 형식 |
| 교환 | DICOM 및 DICOMweb | 내장 메타데이터가 있는 이미지 객체; DICOMweb은 REST 인터페이스입니다 | 모든 스캐너, PACS 및 방사선 뷰어; 웹 뷰어는 DICOMweb을 사용합니다 |
| 레시피 | IHE 프로파일 | 단일 사용 사례를 위한 위의 테스트 조합(XDS, PIX/PDQ, XCA, SWF) | 병원 및 지역 간 문서 공유, 환자 신원, 방사선 워크플로우 |
| 저장 | openEHR | 기록 자체를 위한 아키타입 기반 임상 데이터 모델 | 유럽, 스칸디나비아, 브라질 일부 지역의 병원 및 국가 EHR 플랫폼 |
| 연구 | OMOP CDM | 관찰 연구를 위한 공통 관계형 모델 | 연구 네트워크, 실제 증거, EHDS 재사용 |
| 용어 | SNOMED CT, LOINC, ICD-10/11, ATC, RxNorm, UCUM | 소견, 검사, 진단, 의약품, 단위에 대한 코드 | 위의 모든 표준 내 |
| 신원 | OAuth 2.0, OpenID Connect, SMART on FHIR, IHE XUA | 사용자가 누구이며 앱이 무엇에 액세스할 수 있는지 | 모든 환자 대상 앱 및 모든 EHR 앱 플랫폼 |
계층이 함께 작동하는 방식
의료 상호 운용성 표준의 계층은 동일한 워크플로우에서 각자 하나의 작업을 수행하며 함께 작동합니다. HL7 v2 메시지는 검사 주문을 전달하고, LOINC 및 UCUM은 결과를 코딩하며, openEHR 플랫폼은 이를 저장하고, FHIR API는 SMART on FHIR 로그인 후 환자 앱에 제공하며, CDA 문서는 다른 병원과 공유합니다.
혈액 검사는 하루 만에 네 가지 계층을 모두 보여줍니다. 주문은 HL7 v2 ORM 메시지(교환)로 병동을 떠납니다. 분석기 결과는 LOINC로 코딩된 검사와 UCUM으로 코딩된 단위가 포함된 HL7 v2 ORU로 돌아옵니다(용어). 병원은 이를 자체 데이터베이스, 아마도 openEHR 플랫폼(저장)에 저장합니다. 환자의 앱은 환자가 SMART on FHIR(신원)로 로그인한 후 FHIR API를 통해 Observation으로 읽습니다. 병원이 전체 보고서를 다른 병원과 공유하는 경우, IHE XDS 레지스트리를 통해 CDA 문서로 공유할 수 있습니다. 결과가 나중에 연구 코호트에 합류하면 OMOP으로 변환됩니다.
표준은 경쟁자가 아닙니다. 각 표준은 다른 작업을 위해 구축되었으며, 하나를 다른 것으로 대체하는 것은 일반적으로 이미 작동하는 것을 재구축하는 것을 의미합니다.
어떤 것이 필요하신가요?
어떤 의료 상호 운용성 표준이 필요한지는 작업에 따라 다릅니다. 환자 또는 임상의 앱의 경우 SMART on FHIR를 사용하는 FHIR R4, 기존 병원 시스템과의 연결을 위한 HL7 v2, 이미지의 경우 DICOM 및 DICOMweb, 전체 문서의 경우 CDA 또는 FHIR 문서, 장기 기록 저장을 위한 openEHR, 연구를 위한 OMOP, 그리고 두 시스템이 동일하게 작동해야 할 경우 IHE 프로파일이 필요합니다.
- 환자 또는 임상의를 위한 앱을 구축하는 경우: FHIR R4, 시장의 프로파일(구현 가이드), 로그인을 위한 SMART on FHIR.
- 병원 기존 시스템에 연결하는 경우: 먼저 HL7 v2를 예상하고, 공급업체가 제공하는 경우 FHIR을 사용합니다. HL7 v2 메시지 설명을 참조하세요.
- 이미지를 처리하는 경우: 저장 및 전송에는 DICOM, 브라우저의 모든 것에는 DICOMweb, 메타데이터에만 FHIR ImagingStudy를 사용합니다. DICOMweb 설명 및 ImagingStudy 대 DICOMweb을 참조하세요.
- 전체 문서(요약, 편지)를 교환하는 경우: 의무화된 곳에서는 CDA, 선택할 수 있는 곳에서는 FHIR 문서(유형
document의 번들)를 사용합니다. CDA 및 C-CDA 설명을 참조하세요. - 수십 년 동안 기록을 저장하는 방법을 설계하는 경우: openEHR, 교환 계층으로 FHIR을 사용합니다. openEHR 대 FHIR을 참조하세요.
- 여러 레코드에 대한 연구를 수행하는 경우: OMOP, 소스로 FHIR을 사용합니다. 건강 데이터의 재사용을 참조하세요.
- 두 시스템이 동일하게 작동하도록 하려면: 사용 사례에 맞는 IHE 프로파일을 선택하고 테스트하세요.
Anpheros의 위치
Anpheros Platform은 OAuth 2.0 액세스와 변경 알림을 위한 웹훅을 갖춘 FHIR R4 서버로서 표준 맵의 교환 계층에 위치하며, HL7 v2 ORU, CSV 또는 JSON을 통해 커넥터로부터 검사 결과를 수신합니다. DICOM 이미지는 저장하지 않으며 CDS Hooks 서비스도 제공하지 않습니다. 이러한 기능은 병원 시스템에 남아 있습니다.
Anpheros Platform은 환자 중심 기록에 필요한 리소스(Patient, Observation, Condition, MedicationStatement, DocumentReference, DiagnosticReport, Immunization, Consent, Provenance 등), 액세스를 위한 OAuth 2.0, 변경 알림을 위한 웹훅을 갖춘 FHIR R4 서버입니다. 실험실 결과는 HL7 v2 ORU, CSV 또는 JSON에서 실험실 커넥터를 통해 도착합니다. DICOM 이미지를 저장하지 않으며 CDS Hooks 서비스를 제공하지 않습니다. 이러한 서비스는 병원 시스템에 남아 있으며 기록은 해당 서비스를 가리킵니다.
읽기 순서
의료 상호 운용성 표준을 잘 읽는 순서는 FHIR가 무엇인지, 그리고 HL7 v2와 어떻게 다른지부터 시작합니다. 그 다음 FHIR Observation 리소스, 그 안에서 사용되는 LOINC 및 SNOMED CT 용어집, 이미지의 경우 DICOMweb, 문서의 경우 CDA, 그리고 마지막으로 기록이 저장되는 방식에 대해 FHIR와 비교한 openEHR 순서로 진행됩니다.
이 분야가 처음이라면: FHIR이란 무엇인가 → HL7 대 FHIR → FHIR Observation → LOINC 및 SNOMED CT → DICOMweb → CDA → openEHR 대 FHIR.
관련 페이지
- HL7 대 FHIR
- HL7 v2 메시지 설명
- CDA 및 C-CDA 설명
- DICOMweb 설명
- openEHR 대 FHIR
- FHIR 구현 가이드
- FHIR R4 대 R5
- LOINC 코드는 무엇인가요?
- SNOMED CT는 무엇인가요?
- 개발자를 위한 DICOM 대 FHIR
- FHIR 프로파일 및 확장 설명
- FHIR 용어 서버 설명
- 건강 데이터 규제 지도
- 유럽 및 미국의 국가 전자 건강 기록
- 병원 시스템 통합 설명
- 의료 데이터에 대한 AI
- 건강 데이터의 재사용
- 건강 앱의 보안 및 신원
출처
- HL7 International: 표준
- HL7 FHIR R4 사양
- DICOM 표준, 현재 판
- IHE 기술 프레임워크
- openEHR 사양
- OHDSI OMOP 공통 데이터 모델
- SMART 앱 실행
자주 묻는 질문
FHIR이 다른 모든 표준을 대체하고 있나요?
아니요. FHIR은 사용자 정의 API를 대체하고 있으며, 점진적으로 일부 CDA 문서 교환을 대체하고 있습니다. HL7 v2는 병원 내에서 계속 사용되는 주요 표준이며, DICOM은 이미지에 대한 유일한 표준으로 남아 있습니다. openEHR과 OMOP은 FHIR이 처리하도록 설계되지 않은 질문(저장, 연구)에 대한 답변을 제공합니다.
표준과 IHE 프로파일의 차이점은 무엇인가요?
FHIR 또는 DICOM과 같은 표준은 빌딩 블록을 정의합니다. IHE 프로파일은 특정 블록을 선택하고 옵션을 고정하며, 시스템이 단일 작업을 위해 이를 사용해야 하는 방법을 정확하게 명시하여, IHE 테스트를 통과한 두 공급업체가 프로젝트 없이 함께 작업할 수 있도록 합니다.
국가 건강 시스템은 어떤 표준을 사용하나요?
대부분의 유럽 시스템은 CDA 문서와 HL7 v2로 시작했으며 FHIR API를 추가하고 있습니다. EHDS 교환 형식은 FHIR과 IPS를 기반으로 합니다. 미국은 환자 액세스를 위해 FHIR US Core를, 문서 교환을 위해 C-CDA를 의무화합니다.
SNOMED CT와 LOINC는 어디에 속하나요?
이들은 교환 표준이 아니라 모든 표준 내에서 사용되는 어휘입니다. LOINC 코드는 HL7 v2 OBX 세그먼트, CDA 항목 및 FHIR Observation에서 검사를 식별합니다.
샌드박스에서 무료로 사용해 보세요
5분 만에 첫 FHIR 호출. 환자의 동의가 내장된 HL7 FHIR R4 API: 샌드박스에서 먼저 사용해보고, 자체 앱 또는 병원 시스템을 연결하세요.
무료 · 합성 환자 30명 · 카드 불필요
Anpheros는 환자가 직접 관리하고 어떤 병원과도 공유할 수 있는 의료 기록을 EU 기반의 HL7 FHIR R4 플랫폼에서 구축합니다. 이 가이드들은 건강 정보를 이해하고 정리하는 데 도움을 드리며, 의사의 진료를 대체하지 않습니다.
Anpheros 소개 →