개념
세 표준이 한 흐름에서 맡는 일
진료 흐름 하나를 따라가면 세 표준의 역할이 보인다. 공개 자료가 설명하는 전형적 흐름이다 — 의사가 CT 를 처방하면 처방 정보가 HL7 메시지로 영상 정보 시스템과 중계 시스템에 전달되고, 그 시스템이 관련 항목을 DICOM 검사 목록(Modality Worklist) 항목으로 바꾸며, 장비가 그것을 C-FIND 로 조회 한다.
[처방] [환자·처방 정보] [검사 목록] [촬영] [저장] [판독·조회]
EMR ──HL7 v2──→ RIS/중계 ──DICOM MWL──→ 장비 ──C-STORE──→ PACS ──조회/API──→ 뷰어·AI
(FHIR 등)역할을 나누면 이렇다. 공개 자료는 HL7 v2 가 환자·처방 업무 흐름의 운영 메시징 기반 으로 남아 있고, DICOM 이 검사 목록과 영상 획득을 관리 하며, FHIR 가 임상 접근과 새로운 디지털 서비스를 위한 재사용 가능한 API 를 제공하는 형태로 공존한다고 설명한다.
| 표준 | 주로 다루는 것 | 성격 |
|---|---|---|
| HL7 v2 | 환자 등록·이동·처방·결과 보고 | 메시지. 구분자로 나뉜 세그먼트 |
| DICOM | 영상과 그 메타데이터, 검사 목록, 전송 | 객체 + 서비스 연산 |
| FHIR | 자원 단위 조회·갱신 | 웹 API. 자원 중심 |
QA 에게 중요한 것은 세 표준이 "같은 환자·같은 검사" 를 서로 다른 방식으로 식별한다는 점 이다. 그 사이에서 식별자가 어긋나면 환자가 섞인다 — 이 분야에서 가장 심각한 결함이고, 아래에서 따로 다룬다.
각 표준의 세그먼트·필드·자원 구조, 연산 이름과 식별자 체계는 해당 표준의 공개 문서와 우리 연계 정의서에서 확인한다(원문 확인). 판본과 프로파일에 따라 다르고, 기관마다 사용 범위가 다르다.
DICOM — 객체와 연산
공개 자료가 설명하는 바로, DICOM 메시지 서비스 요소(DIMSE) 가 두 응용 개체가 데이터를 교환하는 연산을 정의한다 — C-STORE 는 인스턴스를 보내고, C-FIND 는 조회하며, C-MOVE 는 제3자에게 영상 전달을 요청하고, C-GET 은 직접 가져온다. 그리고 검사 목록(MWL) 은 장비가 환자 정보와 검사 상세를 서비스 제공자에 조회하게 한다. 각 서비스는 SOP 클래스 로 구분되고 고유 식별자(UID) 를 갖는다.
QA 가 확인할 축이 이렇다.
| 축 | 확인할 것 |
|---|---|
| 지원 선언 | 양쪽이 지원하는 SOP 클래스·전송 구문이 일치하는가 |
| 전송 성공·실패 | 실패 응답을 받았을 때 보낸 쪽이 무엇을 하는가 |
| 부분 전송 | 여러 장 중 일부만 저장된 상태를 알아보는가 |
| 중복 전송 | 같은 인스턴스를 두 번 보내면 어떻게 되는가 |
| 식별자 일관성 | 검사·시리즈·인스턴스 식별자가 유지되는가 |
| 메타데이터 보존 | 중간 단계에서 필드가 지워지거나 바뀌는가 |
| 조회 조건 | 조회 키 조합이 기대대로 결과를 거르는가 |
세 번째가 임상적으로 위험하다. CT 100장 중 80장만 저장되었는데 "완료" 로 보이면, 판독자가 일부가 없는 검사를 전체로 알고 판독 한다. 그래서 장수 일치 검사 가 핵심이고, 레슨 2 의 "0건이면 통과" 형태로 만든다.
여섯 번째가 AI 소프트웨어에 특히 중요하다. 영상이 여러 시스템을 거치는 동안 촬영 조건 관련 필드가 지워지거나 변환되면, 모델이 전제한 입력과 달라진다. 레슨 2 의 집단별 성능 축(촬영 장비·조건) 이 그 필드에 의존 하므로, 필드가 없으면 집단 분석도 못 한다.
익명화가 일으키는 두 문제
이것을 따로 다뤄야 한다. 영상을 연구·검증에 쓰려면 식별 정보를 제거하는데, 그 과정에서 두 문제가 생긴다.
1) 지워야 할 것이 남는다. 레슨 2 에서 짚은 문제다. 영상 화면만 가리고 메타데이터를 그대로 두는 실수, 그리고 덜 알려진 필드나 사적 필드에 식별 정보가 남는 경우. 환자 이름을 지웠는데 다른 필드에 등록번호가 남아 있는 식이다.
2) 남겨야 할 것이 지워진다. 익명화 도구가 넓게 지우면 촬영 조건·장비 정보 까지 날아간다. 그러면 레슨 2 의 집단별 성능 분석이 불가능해지고, 모델 입력 전제도 확인할 수 없다.
QA 가 할 일은 양방향 검사 다.
| 검사 | 통과 조건 |
|---|---|
| 식별 정보 잔존 | 정해진 필드 목록에 식별 패턴이 없음 → 0건 |
| 사적·비표준 필드 | 처리 정책에 따라 처리되었음 |
| 필요 필드 보존 | 분석에 쓸 필드가 남아 있음 → 결측 0건 |
| 일관된 가명 | 같은 환자가 같은 가명으로 매핑됨(레슨 2 의 환자 단위 분리 전제) |
| 매핑표 보관 | 원본 대응표가 통제된 곳에 있고 접근 기록이 있는가 |
네 번째가 레슨 2 와 직결된다. 가명이 일관되지 않으면 같은 환자가 다른 환자로 보이고, 환자 단위 분리가 깨진다. 식별자 교집합 검사가 통과하는데 실제로는 누출인 상태가 만들어진다.
지워야 하는 필드 목록과 처리 정책은 표준의 익명화 관련 문서와 조직 규정에서 확인한다(원문 확인). 이 레슨에서 목록을 적지 않는다 — 판본과 정책에 따라 다르다.
HL7 v2 — 메시지와 필드
HL7 v2 는 구분자로 나뉜 세그먼트 구조의 메시지다. 환자 정보·처방·결과 보고 같은 업무 흐름이 메시지 유형으로 정의되어 있다. 세그먼트와 필드 이름, 메시지 유형, 사용 범위는 해당 판본 문서와 우리 기관의 연계 정의서에서 확인한다(원문 확인).
HL7 v2 검증에서 QA 가 다룰 고유 문제가 넷이다.
1) 선택 필드와 기관별 사용. 표준이 선택으로 둔 필드를 기관마다 다르게 쓴다. 그래서 "표준에 맞는다" 와 "이 기관에서 통한다" 가 다르다. 검증 기준은 표준이 아니라 합의된 연계 정의서 다. 정의서가 없으면 그것이 첫 번째 지적이다.
2) 구분자와 이스케이프. 환자 이름이나 메모에 구분자와 같은 문자 가 들어가면 메시지 구조가 깨진다. 이름에 특수 문자가 있는 경우, 메모에 줄바꿈이 있는 경우가 실제로 문제를 만든다. 이스케이프 처리 시험 이 필요하다.
3) 인코딩과 문자. 한글, 한자 이름, 외국인 이름의 문자 집합 처리. 중간 시스템이 변환하면서 깨지는 경우가 있고, 깨진 채 전달되면 환자 이름이 다른 사람처럼 보인다.
4) 순서와 중복. 메시지가 순서를 바꿔 도착하거나 두 번 도착하는 경우. 환자 정보 수정 메시지가 등록 메시지보다 먼저 오면 어떻게 되는가. 멱등 처리가 있는가 — 모듈 41 레슨 2, 모듈 62 레슨 4 의 중복 처리와 같은 구조다.
두 번째와 세 번째가 "경계에서 값이 변하는" 전형 이다. 그래서 특수 문자·다국어 이름을 포함한 시험 데이터 집합 을 만들어 두는 것이 이 영역의 기본 자산이다.
FHIR — 자원과 프로파일
FHIR 는 자원 단위의 웹 API 로, 환자·관찰·진단 보고 같은 자원을 REST 로 다룬다. 그리고 프로파일과 구현 가이드 로 특정 환경의 사용 규칙을 정한다. 자원 종류, 필수 요소, 검색 매개변수, 프로파일 규칙은 해당 판본 문서와 적용 구현 가이드에서 확인한다(원문 확인).
QA 가 다룰 고유 문제가 넷이다.
1) 프로파일 준수. 표준 자원에 우리 환경의 제약 이 추가된다 — 필수 요소, 값 집합, 카디널리티. "표준 FHIR 로는 유효한데 프로파일을 위반" 하는 경우가 생기고, 검증 도구로 프로파일 검증을 돌리는지 확인한다.
2) 참조 무결성. 자원이 서로를 참조한다. 참조 대상이 없거나(고아), 순환하거나, 다른 환자의 자원을 참조 하는 경우. 마지막이 환자 섞임의 경로다.
3) 검색과 페이지 나누기. 검색 조건이 기대대로 거르는가. 결과가 많을 때 나뉘어 오는데 중복·누락 없이 전부 받는가. 모듈 12 의 API 시험 기법이 그대로 쓰인다.
4) 갱신 충돌. 두 시스템이 같은 자원을 동시에 갱신하면 어떻게 되는가. 버전 기반 제어가 있는가, 나중 것이 이기는가.
세 번째의 페이지 나누기 가 임상적으로 위험할 수 있다. 환자의 과거 기록을 조회하는데 일부만 받고 전체로 알면, 중요한 기록이 없는 것으로 보인다.
식별자 — 환자가 섞이는 경로
이 레슨에서 가장 중요한 부분이다. 세 표준이 각각 식별자 체계를 갖고, 그 사이 매핑에서 환자가 섞일 수 있다.
전형적 경로다.
| 경로 | 상황 |
|---|---|
| 매핑 오류 | 시스템 간 환자 번호 대응이 틀린다 |
| 동명이인 | 이름·생년월일만으로 매칭하면 다른 사람이 합쳐진다 |
| 번호 재사용 | 과거 번호가 다른 환자에게 재부여되었다 |
| 임시 식별자 | 응급 환자의 임시 번호가 나중에 정식 번호로 합쳐지는 과정 |
| 병합·분리 | 중복 등록을 합치거나 잘못 합친 것을 분리할 때 |
| 외부 의뢰 | 다른 기관에서 온 영상의 식별자 체계가 다르다 |
| 익명화 매핑 | 레슨 2·위에서 다룬 가명 일관성 문제 |
네 번째와 다섯 번째가 특히 어렵다. 응급실에서 신원 미상 환자에게 임시 번호를 주고, 나중에 신원이 확인되면 정식 번호와 합친다. 그 과정에서 이미 촬영된 영상과 이미 보고된 결과 가 올바른 환자에게 따라가야 한다.
다섯 번째의 분리 는 더 위험하다. 잘못 합친 두 환자를 분리할 때 어느 기록이 누구의 것인지 를 가려야 하고, 틀리면 두 환자 모두의 기록이 오염된다.
QA 가 설계할 검사다.
| 검사 | 확인 |
|---|---|
| 매핑 유일성 | 한 식별자가 둘 이상에 매핑되지 않음 → 0건 |
| 역방향 유일성 | 한 환자에 여러 식별자가 매핑될 때 그것이 의도된 것인가 |
| 영상-환자 일치 | 영상 메타데이터의 환자 정보와 시스템 기록이 일치 → 불일치 0건 |
| 결과-환자 일치 | 보고된 결과가 올바른 환자에 붙어 있음 |
| 병합 후 추적 | 병합 전 기록이 모두 따라왔는가. 건수 일치 |
| 분리 후 추적 | 분리된 기록이 올바른 쪽에 갔는가 |
| 동명이인 처리 | 이름·생년월일이 같은 경우 합쳐지지 않는지 |
세 번째가 가장 직접적인 안전 검사 다. 영상 메타데이터와 시스템 기록의 환자 정보를 대조하는 검사 를 주기적으로 돌리면 섞임을 발견할 수 있다. 그리고 AI 소프트웨어 입장에서는 입력 영상의 환자 정보와 결과를 붙일 환자가 일치하는지 확인하는 것이 필수다 — 틀리면 다른 환자의 판독 결과 가 전달된다.
일곱 번째를 일부러 시험해야 한다. 이름과 생년월일이 같은 시험 데이터를 만들어 넣고 합쳐지지 않는지 확인한다. 흔하지 않지만 발생하고, 발생하면 심각하다.
시각 — 순서가 뒤집히면 진료가 뒤집힌다
의료 데이터에는 여러 시각이 섞인다. 모듈 62 레슨 4 의 네 시각 문제가 의료에서는 이렇게 나타난다.
| 시각 | 뜻 |
|---|---|
| 처방 시각 | 의사가 지시한 시각 |
| 촬영 시각 | 장비가 영상을 얻은 시각 |
| 저장 시각 | 시스템에 들어온 시각 |
| 판독 시각 | 결과가 작성된 시각 |
| 보고 시각 | 결과가 전달된 시각 |
순서가 뒤집히면 임상적으로 틀린 해석 이 생긴다. 치료 전 영상과 치료 후 영상의 순서가 뒤바뀌면 경과 판단이 반대가 된다. 그리고 장비 시계가 틀어져 있으면 그 순서가 실제로 뒤집힌다.
QA 가 확인할 것은 셋이다.
- 시각 동기 — 장비·시스템 시계가 맞는가. 허용 오차가 얼마인가
- 시간대·표기 — 시간대 정보가 있는가, 서머타임이 있는 환경인가, 표기 형식이 일관된가
- 순서 역전 검사 — 논리적으로 불가능한 순서를 찾는 검사 (촬영보다 이른 처방 아님, 판독보다 이른 촬영 아님)
세 번째를 "0건이면 통과" 검사로 만들어 두면 시계 문제를 자동으로 잡는다.
연계 시험의 실무 — 양쪽을 다 만들 수 없다
상호운용성 시험의 현실적 어려움이 있다. 상대 시스템을 우리가 통제하지 못한다. 병원의 EMR, 다른 회사의 PACS, 장비 제조사의 소프트웨어.
그래서 세 층으로 접근한다.
| 층 | 수단 | 무엇을 확인 |
|---|---|---|
| 메시지·객체 단위 | 샘플 파일·메시지로 파싱·생성 검증 | 형식, 필드 처리, 경계값 |
| 모의 상대 | 모의 서버·모의 장비 | 연산 흐름, 오류 응답, 비정상 상황 |
| 실제 연계 | 상대 시스템과 직접 | 실제 조합에서의 동작 |
두 번째 층의 모의 상대가 핵심 이고, 모듈 62 레슨 3·모듈 41 레슨 7 에서 반복한 원칙이 그대로다 — 정상 응답만 만드는 모의 서버는 가치가 거의 없다. 비정상 모드가 필요하다.
| 비정상 모드 | 무엇을 드러내는가 |
|---|---|
| 지연·무응답 | 타임아웃 처리, 재시도 |
| 거부 응답 | 실패 시 보낸 쪽의 처리 |
| 부분 성공 | 일부만 저장된 상태 처리 |
| 형식 깨진 메시지 | 파싱 실패 처리. 깨진 채 받아들이지 않는가 |
| 필수 필드 누락 | 거부하는가, 빈 값으로 저장하는가 |
| 예상 밖 값 | 정의되지 않은 코드, 범위 밖 값 |
| 순서 뒤바뀜·중복 | 멱등 처리 |
| 다른 환자 정보 | 섞임을 거부하는가 |
네 번째와 다섯 번째가 중요하다. 깨진 메시지나 필수 필드가 없는 메시지를 조용히 받아들여 빈 값으로 저장 하면, 그 환자의 기록이 불완전해진 채 정상으로 보인다.
마지막 모드가 안전 검사 다. 일부러 다른 환자 정보를 보내 거부되는지 확인한다.
세 번째 층(실제 연계) 은 기회가 제한된다. 병원 시스템에 접근하는 것은 일정·권한·운영 영향이 걸린 일이다. 그래서 아래 두 층에서 최대한 걸러내고 실제 연계에서는 확인만 하는 배분이 필수다 — 모듈 62 레슨 3, 모듈 63 레슨 4, 모듈 65 레슨 1 에서 반복한 원칙이다.
적합성 선언 문서를 먼저 읽는다
연계 검증을 시작하기 전에 읽을 문서가 있다. 각 제품이 자신이 무엇을 지원하는지 선언한 문서 다. DICOM 쪽에는 적합성 선언서가 있고, HL7·FHIR 쪽에는 연계 정의서와 구현 가이드가 있다.
QA 가 할 일은 양쪽 선언을 대조하는 것 이다.
[우리 제품 선언] ←─대조─→ [상대 제품 선언]
↓
겹치는 범위 = 실제로 연계되는 것
겹치지 않는 범위 = 연계되지 않거나 제약이 있는 것겹치지 않는 범위가 질의 목록 이 된다. 우리는 지원하는데 상대가 안 하는 것, 반대인 것. 이 대조를 먼저 하면 "왜 안 되지" 를 찾는 시간 이 크게 줄어든다.
이 대조를 안 하고 시험을 시작하는 것 이 이 영역의 가장 흔한 비효율이다. 지원하지 않는 기능을 시험하고 "안 된다" 고 결함을 올리게 된다.
데이터 취급
레슨 2 와 같은 원칙이다. 연계 시험에 쓰는 데이터도 환자 데이터일 수 있다.
- 시험 데이터는 생성·가명 처리된 것 을 쓴다. 운영 데이터 사용은 승인 절차를 거친다(모듈 41 레슨 10 의 구조)
- 메시지 로그에 환자 정보가 남는다. 로그 보관·접근·반출이 통제되어야 한다
- 운영 환경에 시험 데이터를 넣지 않는다. 시험 환자가 운영 기록에 섞이면 지우는 것이 어렵고, 진료에 영향을 준다
- 시험 데이터에 식별 표식 을 붙여 나중에 걸러낼 수 있게 한다 (모듈 62 레슨 3 의 원칙)
세 번째가 실제 사고로 이어진다. 연계 시험 중 시험 환자 정보가 운영 PACS 나 EMR 에 들어가면, 그 기록을 삭제하는 것 자체가 절차를 요구하고 일부는 남는다.
실무에서 왜 필요한가
진료 현장 소프트웨어의 결함 중 연계에서 오는 것이 가장 많고 가장 찾기 어렵다. 우리 제품은 정상이고 상대도 정상인데, 사이에서 값이 변한다.
그리고 그 결함의 결과가 임상적으로 심각하다. 일부만 저장된 검사를 전체로 알고 판독하거나, 다른 환자의 결과가 붙거나, 영상 순서가 뒤집혀 경과 판단이 반대가 되는 일. 기능 결함이 아니라 환자 안전 문제 다.
QA 가 기여하는 가장 큰 지점은 식별자 대조 검사 다. 영상 메타데이터의 환자 정보와 시스템 기록을 대조하는 검사를 주기적으로 돌리는 것. 아무도 하지 않는 경우가 많고, 돌리면 실제로 불일치가 나온다.
두 번째는 적합성 선언 대조 다. 시험을 시작하기 전에 양쪽 선언을 겹쳐 보면 연계되지 않는 범위가 먼저 드러나고, 지원하지 않는 기능을 시험하느라 쓰는 시간이 사라진다. 몇 시간의 작업으로 몇 주를 줄인다.
세 번째는 비정상 모드를 갖춘 모의 상대 를 요구하는 것이다. 연계 결함은 정상 응답에서 나오지 않는다. 깨진 메시지, 필수 필드 누락, 다른 환자 정보를 만들 수 없으면 그 결함은 운영에서 처음 만난다.
네 번째는 특수 문자·다국어 이름 시험 데이터 집합 이다. 구분자와 같은 문자, 한자 이름, 긴 이름. 이것으로 경계에서 값이 변하는 지점을 찾는다.
다섯 번째는 익명화 양방향 검사 다. 지워야 할 것이 남았는지와 남겨야 할 것이 지워졌는지 를 함께 본다. 후자를 보는 사람이 거의 없고, 그것이 레슨 2 의 집단별 분석을 불가능하게 만든다.
채용시장에서의 위치
이 영역은 의료정보 솔루션 기업(EMR·PACS·OCS), 의료 AI 기업의 연계 담당, 병원의 의료정보팀, 그리고 의료기기 제조사의 연계 검증 자리다. 공고에는 "HL7", "DICOM", "FHIR", "의료정보 연계", "PACS 연동", "상호운용성" 같은 말이 적힌다.
특징은 수요가 꾸준하고 공급이 적다 는 점이다. 표준이 셋이고 각각 판본과 프로파일이 있어 학습 비용이 크다. 그리고 한 번 익히면 기관을 옮겨도 쓰인다 — 어느 병원이나 같은 표준을 쓴다.
면접에서 가르는 질문이 분명하다. "연계 시험을 어떻게 시작하시겠습니까." "샘플 메시지로 테스트합니다" 로 답하면 약하고, 적합성 선언 대조 → 메시지 단위 → 모의 상대(비정상 모드) → 실제 연계 세 층으로 답하면 즉시 구분된다. 그리고 "환자가 섞이는 것을 어떻게 막습니까" — 식별자 대조 검사와 병합·분리 추적을 들면 실무자로 읽힌다.