# FHIR vs HL7 v2: 실제적인 차이점

> 개발자를 위한 HL7 v2 메시지와 FHIR 리소스 비교: 형식, 전송, 동일한 검사 결과, 번역 함정, 그리고 Anpheros에서 v2를 지원하는 경우.

Source: https://developers.anpheros.com/ko/guides/fhir-vs-hl7-v2

**HL7 v2는 1980년대 후반부터 병원 시스템에서 사용되어 온 메시지 형식으로, 네트워크 연결을 통해 시스템 간에 푸시되는 "환자 입원" 또는 "검사 결과 준비 완료"와 같은 파이프 구분(pipe-delimited) 이벤트입니다. 반면 HL7 FHIR은 웹 API 표준으로, 애플리케이션이 HTTPS를 통해 JSON 형식으로 환자(Patient) 및 관찰(Observation)과 같은 리소스를 읽고 씁니다.** 이 둘은 한 번 선택하면 끝나는 대안이 아닙니다. 대부분의 병원은 내부적으로 여전히 v2를 사용하고 있으며, 새로운 애플리케이션과 환자 대상 API는 FHIR을 사용합니다. 통합 작업은 종종 한 형식을 다른 형식으로 번역하는 과정입니다. 이 페이지에서는 코드를 작성할 때 중요한 지점을 중심으로 두 형식을 비교하고, 동일한 데이터를 두 형식 모두에서 보여주며, Anpheros에서 v2를 지원하는 경우를 설명합니다.

## 나란히 비교

| | HL7 v2 | HL7 FHIR R4 |
|---|---|---|
| 스타일 | 이벤트 기반 메시지 (입원, 주문, 결과) | 생성, 읽기, 업데이트, 검색하는 리소스 |
| 형식 | 줄 바꿈으로 구분된 텍스트 세그먼트, 필드는 `\|`, 컴포넌트는 `^` | JSON (또는 XML) |
| 전송 | 일반적으로 병원 네트워크 내 TCP를 통한 MLLP | HTTPS REST |
| 쿼리 | 제한적; 시스템이 주로 푸시 | 검색 매개변수, `_include`, 히스토리 |
| 보안 | 네트워크 수준 (VPN, 프라이빗 링크) | OAuth 2.0 / SMART on FHIR, TLS, 스코프 |
| 유연성 | 많은 선택 필드 및 로컬 Z-세그먼트; 모든 인터페이스는 협상됨 | 기본 리소스 및 프로필 (US Core, IPS, European IGs) |
| 일반적인 사용자 | 병원 내 EHR, 실험실, 영상의학, 청구 시스템 | 앱, 환자 접근 API, 조직 간 교환, AI |

가장 일반적인 v2 메시지:

| 메시지 | 의미 | 가장 가까운 FHIR 리소스 |
|---|---|---|
| ADT^A01, A03, A08 | 환자 입원, 퇴원, 업데이트 | `Patient`, `Encounter` |
| ORM / OML | 검사 주문 | `ServiceRequest` |
| ORU^R01 | 결과 준비 | `Observation`, `DiagnosticReport` |
| SIU | 예약 | `Appointment` |
| MDM | 문서 | `DocumentReference` |

## 두 가지 모두에서 동일한 검사 결과

ORU^R01 결과 라인 (OBX 세그먼트):

```
OBX|1|NM|2093-3^Cholesterol^LN||212|mg/dL|<200|H|||F|||20261002074500
```

Anpheros가 해당 메시지를 가져온 후 저장하는 HL7 FHIR R4 Observation과 동일한 결과:

```json
{
  "resourceType": "Observation",
  "status": "final",
  "category": [{"coding": [{"system": "http://terminology.hl7.org/CodeSystem/observation-category", "code": "laboratory"}]}],
  "code": {"coding": [{"system": "http://loinc.org", "code": "2093-3", "display": "Cholesterol [Mass/volume] in Serum or Plasma"}], "text": "Cholesterol"},
  "effectiveDateTime": "2026-10-02T07:45:00Z",
  "valueQuantity": {"value": 212.0, "unit": "mg/dL"},
  "interpretation": [{"coding": [{"system": "http://terminology.hl7.org/CodeSystem/v3-ObservationInterpretation", "code": "H"}]}],
  "referenceRange": [{"high": {"value": 200.0, "unit": "mg/dL"}}]
}
```

필드별: OBX-3은 `code`이 되고, OBX-5 및 OBX-6은 `valueQuantity`이 되고, OBX-7은 `referenceRange`, OBX-8은 `interpretation`, OBX-11은 `status`, OBX-14는 `effectiveDateTime`이 됩니다. HL7은 세그먼트, 데이터 유형 및 어휘에 대한 매핑을 포함하는 공식 [HL7 Version 2 to FHIR](https://build.fhir.org/ig/HL7/v2-to-fhir/) 구현 가이드를 게시합니다.

## 번역이 잘못되는 경우

- **시간대.** `20261002074500`와 같은 v2 타임스탬프는 종종 오프셋을 포함하지 않습니다. 발신자의 시간대를 알아야 합니다. FHIR은 시간이 있는 경우 항상 시간대를 요구합니다. (Anpheros는 오프셋이 없는 v2 시간을 UTC로 읽습니다. 오프셋이 있는 경우 보내주세요.)
- **로컬 코드.** 많은 실험실에서 LOINC 대신 OBX-3에 자체 코드를 사용합니다. 좋은 번역은 로컬 코드를 유지하고 가능한 경우 LOINC에 매핑하며, 삭제하지 않습니다.
- **반복 전송.** v2 발신자는 타임아웃 시 재전송합니다. 결과당 안정적인 식별자가 없으면 FHIR 저장소가 중복으로 채워집니다.
- **모든 것이 선택 사항.** 동일한 필드가 비어 있거나 반복되거나 두 발신자가 다르게 사용할 수 있습니다. FHIR 측을 검증하세요. [FHIR R4 validator](https://developers.anpheros.com/tools/fhir-validator)는 번역된 리소스에 누락된 항목을 보여줍니다.
- **수정.** v2 결과 상태 `C` (수정됨)은 기존 Observation을 업데이트하고 기록을 유지해야 하며, 두 번째 Observation을 생성해서는 안 됩니다.

## 언제 무엇을 사용해야 할까

- **병원 내부, 기존 시스템 간 통신:** 일반적으로 시스템들은 v2를 사용합니다. 통합 엔진이 메시지를 라우팅하고 변환합니다.
- **앱, 환자 접근 API 또는 조직 간 통신 구축:** FHIR, OAuth 및 동의와 함께 사용합니다.
- **AI 또는 분석 데이터 제공:** FHIR은 쿼리 가능하고, 코딩되어 있으며, 버전 관리가 가능하므로 사용합니다.
- **둘 다 사용:** 일반적인 실제 시나리오 — 실험실 또는 EHR에서 v2 수신, FHIR 저장, 애플리케이션에 FHIR 제공.

## Anpheros의 역할

Anpheros는 FHIR R4 형식으로 환자 기록을 저장하며, 단 하나의 HL7 v2 메시지 유형만 수락합니다: **ORU^R01 검사 결과**. 이 메시지는 HTTPS를 통해 [lab connector](https://developers.anpheros.com/ko/guides/lab-connector) (`POST /v1/patients/{id}/labs/import`, `Content-Type: x-application/hl7-v2+er7` 사용)로 전송됩니다. 각 OBX는 LOINC 코드, 참조 범위 및 해석을 포함하는 검사 관찰(laboratory Observation)로 변환됩니다. 보고서 ID는 출처(provenance)에 저장되며, 재전송된 보고서는 건너뜁니다. 새로운 값과 함께 수정된 결과(OBX-11 = `C`)는 상태 `amended`인 새로운 관찰로 저장됩니다. 원본은 그대로 유지되므로, 소스에서 수정 사항을 보내는 경우 이전 관찰을 `entered-in-error`로 표시하거나 FHIR API를 통해 업데이트해야 합니다. 관련 예시는 [Lab results API](https://developers.anpheros.com/ko/guides/lab-results-api)에서 확인할 수 있습니다.

Anpheros는 다른 v2 메시지(ADT, 주문, 예약)를 수락하지 않으며, MLLP에서 수신 대기하지 않고 v2 메시지를 전송하지도 않습니다. 이러한 경우에는 Anpheros 앞에 통합 엔진을 두어 FHIR로 변환하고 API를 통해 기록합니다.

## 자주 묻는 질문

### FHIR이 HL7 v2를 대체하나요?
곧 대체되지는 않을 것입니다. v2는 대부분의 병원에서 여전히 사용되고 있으며, 기존 시스템에 통합되어 있기 때문에 계속해서 중요한 역할을 할 것입니다. FHIR은 앱, 환자 접근, 조직 간 교환 등에서 v2를 보완하며 성장하고 있으며, 두 표준은 종종 상호 변환을 통해 공존합니다.

### MLLP란 무엇인가요?
Minimal Lower Layer Protocol: TCP 연결을 통해 v2 메시지를 프레임하는 간단한 방법으로, 각 메시지 주위에 시작 및 종료 문자를 사용하고 응답으로 ACK(Acknowledgement)를 받습니다. FHIR은 대신 HTTPS를 사용합니다.

### HL7 v2 메시지를 FHIR로 자동 변환할 수 있나요?
대부분 가능합니다. HL7의 v2-to-FHIR 구현 가이드에는 표준 매핑이 제공되며, 통합 엔진은 이를 구현합니다. 로컬 코드, Z-세그먼트, 시간대 및 각 발신자가 선택 필드를 사용하는 방식에 대해서는 수동 작업이 필요할 수 있습니다.

### Anpheros는 HL7 v2를 지원하나요?
네, 검사 결과에 대해서는 지원합니다. 실험실 커넥터로 HTTPS를 통해 전송된 ORU^R01 메시지는 FHIR Observations로 변환됩니다. 다른 v2 메시지 유형 및 MLLP 연결은 지원되지 않습니다.

## 관련 자료

- [HL7 v2를 FHIR로 매핑](https://developers.anpheros.com/ko/guides/hl7-v2-to-fhir-mapping): 세그먼트 및 필드 매핑, 변환기 제공
- [검사 결과 API: HL7 v2, FHIR 및 LOINC](https://developers.anpheros.com/ko/guides/lab-results-api)
- [FHIR 레코드에 검사 결과 가져오기](https://developers.anpheros.com/ko/guides/import-lab-results-fhir)
- [의료 데이터 상호 운용성](https://developers.anpheros.com/ko/guides/interoperability)
- [DICOM 대 FHIR: 영상 데이터 및 임상 데이터](https://developers.anpheros.com/ko/guides/dicom-vs-fhir)
- [FHIR 플랫폼](https://developers.anpheros.com/ko/guides/fhir)