[HealthCare] HL7 v3의 실패 이유 정리

HL7 v3의 실패 이유 정리

헬스데이터 스타트업이라면 HL7 v2 말고도 v3의 역사와 실패 이유를 반드시 알아야 한다.
이 글에서는 HL7 v3가 어떤 배경에서 등장했고, 왜 실패했는지, 그리고 이후 표준에 어떤 영향을 미쳤는지 정리한다.

---

1. HL7 v3란?

• 2000년대 초반 HL7이 새롭게 만든 표준이다.
• XML 기반으로 더 엄격하고 체계적인 데이터 구조를 제공한다.
• 메시지를 Reference Information Model (RIM) 이라는 추상 데이터 모델에 맞춰 표현한다.
• 목표: v2의 자유로운(때로는 제각각인) 메시지 구조 문제를 해결하고, 전 세계적으로 일관된 모델을 제시하는 것.

---

2. HL7 v3의 특징과 장단점

장점

• 구조적 일관성: 모든 메시지가 RIM이라는 공통 모델을 기반으로 작성된다.
• 표준 코드 체계 사용: LOINC, SNOMED CT 같은 코드 시스템을 활용하여 의미를 명확히 표현할 수 있다.
• 기계 판독성: XML 기반이므로 파싱과 검증이 용이하다.

단점

• 과도한 복잡성:
  • 메시지 안에 classCode, moodCode, codeSystem, interpretationCode 등 필수 속성이 너무 많다.
  • 개발자는 값 하나를 표현하기 위해 수많은 태그와 속성을 채워야 한다.
• 깊은 중첩 구조:
  • Observation 안에 component/observation이 계속 중첩된다.
  • 사람이 읽고 쓰기에 가독성이 떨어지고, 시스템 구현도 어렵다.
• nullFlavor 문제:
  • 값이 없을 때도 단순히 비워둘 수 없고 nullFlavor="UNK" 같은 코드로 반드시 표현해야 한다.
  • 각 기관이 이를 다르게 해석하면서 상호운용성이 깨졌다.
• 국가별 Implementation Guide(IG) 의존:
  • HL7 v3 자체만으로는 너무 추상적이어서, 실제 사용을 위해서는 각 나라/기관이 IG를 별도로 만들어야 했다.
  • 결과적으로 “국제 표준”인데도 불구하고, 국경을 넘으면 호환성이 보장되지 않았다.

---

3. 결과: 왜 실패했는가?

• 현실적 구현 난이도 ↑
  → 복잡한 XML 구조와 필드 정의 때문에 실제 시스템에 적용하기 어려웠다.

• 기관별 해석 차이 ↑
  → 같은 모델을 두고도 IG마다 다르게 구현, 결국 “표준이지만 표준이 아닌” 상황이 되었다.

• 개발자/벤더 채택 저조
  → v2 메시지는 단순해서 인터페이스 개발자가 빠르게 붙일 수 있었지만, v3는 학습곡선이 너무 높았다.

• 상호운용성 확보 실패
  → 원래 목표는 글로벌 상호운용성 확대였으나, 오히려 v2보다도 통합이 어려워졌다.

➡️ 결국 HL7 v3는 국제적으로 널리 쓰이지 못하고 사실상 실패한 표준이 되었다.

---

4. 이후로 이어진 흐름

• CDA (Clinical Document Architecture)

  • v3의 일부 기술을 가져와 문서 중심 교환 표준으로 자리 잡았다.
  • 환자 퇴원요약서, 진료 기록, 검사 리포트 등 문서 단위 교환에 성공적으로 적용.
  • 지금도 국가 단위 EHR 프로젝트나 보험청구에서 쓰인다.

• FHIR (Fast Healthcare Interoperability Resources)

  • v3의 복잡성을 교훈 삼아 2010년대에 등장.
  • JSON/XML 기반 + REST API 친화적.
  • 구조가 단순하고 직관적이라 빠르게 전 세계에서 채택 중.

---

5. 정리

• HL7 v3는 이론적으로는 완벽했으나,

  • 너무 복잡한 XML 구조,
  • nullFlavor 등 과도한 제약,
  • 국가별 IG에 의존한 해석 차이
    때문에 실제 현장에서는 실패했다.

• 그러나 v3의 시도는 헛되지 않았다.

  • CDA라는 문서 교환 표준이 성공적으로 자리잡았고,
  • 이후 FHIR이 “현실적이고 개발자 친화적인 표준”으로 발전할 수 있는 기반이 되었다.

👉 요약하면, v3는 실패했지만 CDA와 FHIR로 이어진 진화 과정에서 중요한 디딤돌이었다.