간단 답변: HL7 v2에서 오더(검사, 영상 검진, 약물 등)는 2.5.1 버전까지는 ORM^O01 메시지로, 2.4 버전부터는 OML^O21 검사 오더 메시지로 전송됩니다. 두 메시지 모두 환자(PID), 방문(PV1), 오더를 제어하는 ORC 세그먼트(신규, 취소, 보류, 상태 변경, 의뢰자 및 수행자 번호 포함) 및 주문된 내용, 주문자, 주문 시기를 명시하는 OBR 세그먼트를 포함합니다. 수행 시스템은 ORR(또는 OML의 경우 ORL)로 응답하고, 나중에 결과를 ORU로 반환합니다. ORC+OBR에 해당하는 FHIR 개념은 ServiceRequest입니다.
검사 오더, 세그먼트별 설명
HL7 v2 검사 오더 메시지(ORM^O01)는 세그먼트로 구성됩니다. MSH는 메시지 유형과 버전을 지정하고, PID는 환자를 식별하며, PV1은 방문 정보를 설명합니다. ORC는 오더 제어 코드, 플레서 및 필러 오더 번호, 우선순위 및 오더 의사 정보를 담고 있습니다. OBR은 요청된 검사를 LOINC 코드와 채취 시간과 함께 명시하고, DG1은 진단 근거를 제공합니다.
MSH|^~\&|EHR|GENHOSP|LIS|CENTRALLAB|20260314091200||ORM^O01^ORM_O01|MSG0001|P|2.5.1
PID|1||MRN-00012345^^^GENHOSP^MR||DOE^JANE||19800523|F|||12 High Street^^Leeds^^LS1 4AB^GB
PV1|1|O|CLINIC-3^^^GENHOSP||||42^SMITH^JOHN^^^Dr
ORC|NW|PLC-778812^EHR|||||^^^20260314093000^^R||20260314091200|42^SMITH^JOHN
OBR|1|PLC-778812^EHR||4548-4^Hemoglobin A1c/Hemoglobin.total in Blood^LN|||20260314093000||||||||42^SMITH^JOHN
DG1|1||E11.9^Type 2 diabetes mellitus without complications^I10
- MSH-9
ORM^O01^ORM_O01은 메시지 유형, 트리거 이벤트 및 구조를 나타냅니다. MSH-12는 버전을 나타냅니다. - PID는 환자를 식별하며, PID-3는 발급 기관 및 유형(
MR, 의료 기록 번호)과 함께 식별자를 포함합니다. - PV1은 방문 정보를 제공합니다: 외래(
O), 위치, 담당 의사. - ORC-1은 오더 제어 코드입니다:
NW신규 오더,CA취소 요청,OC오더 취소,HD보류,RL해제,SC상태 변경,OK오더 수락,UA수락 불가,XO오더 변경,DC중단. ORC-2는 의뢰자 오더 번호(의뢰 시스템에서 할당), ORC-3은 수행자 오더 번호(검사실에서 할당, 응답 시까지 비어 있음)입니다. ORC-7은 시간 및 우선순위(R일반,S긴급,A가능한 한 빨리)를 포함합니다. ORC-12는 주문한 의사입니다. - OBR-4는 보편 서비스 식별자입니다: 주문된 내용, 코드로 표시(여기서는 LOINC,
LN). OBR-7은 검체 채취 또는 관찰 날짜-시간입니다. OBR-16은 주문한 의사를 반복합니다. 검사 오더의 경우, 검체 정보는 이전 버전에서는 OBR-15에, 2.5 버전부터는 전용 SPM 세그먼트에 있습니다. - DG1은 오더를 정당화하는 진단 정보를 포함합니다.
여러 검사가 포함된 동일한 오더의 경우, 각 검사마다 고유한 OBR-1 세트 ID를 가진 ORC/OBR 쌍이 반복됩니다.
ORM 대 OML
ORM^O01은 일반적인 HL7 v2 오더 메시지로, 검사, 영상의학, 약국 및 소모품에 대한 느슨한 구조입니다. 버전 2.4에 도입된 OML은 실험실별 오더 메시지로, 트리거 O21, O33, O35와 검체 및 용기를 위한 명시적인 SPM 및 SAC 세그먼트를 포함합니다. 대부분의 병원-실험실 인터페이스는 여전히 ORM^O01을 사용하며, OML은 최신 실험실 시스템 및 IHE 프로파일에서 사용됩니다.
ORM^O01은 일반 오더 메시지로, 검사, 영상, 약국, 식이 및 물품에 대해 하나의 구조를 사용했기 때문에 유연성이 떨어졌습니다. 2.4 버전부터 HL7는 여러 트리거(O21 (검사별 오더), O33 (검체별 오더), O35 (검체 및 용기별 오더))와 검체 및 용기에 대한 SPM 및 SAC 세그먼트를 포함하는 더 엄격한 구조를 가진 OML(검사 오더)을 도입했습니다. OMG(일반 임상 오더), OMI(영상), OMP(약국)도 같은 패턴을 따랐습니다. 실제로는 대부분의 병원-검사실 인터페이스는 여전히 2.3.1 또는 2.5.1 버전의 ORM^O01으로 실행되며, OML은 최신 검사실 시스템과 IHE의 Laboratory Testing Workflow 프로파일에서 사용됩니다.
응답
HL7 v2 오더는 두 가지 응답을 받습니다. 즉각적인 ACK(MSA-1 AA, AE 또는 AR)는 메시지가 수신되고 파싱되었음을 확인합니다. 그런 다음 애플리케이션 응답으로, ORM의 경우 ORR^O02, OML의 경우 ORL^O22가 OK 또는 UA와 함께 ORC를 반복하고 필러 오더 번호인 ORC-3을 채웁니다. 결과는 나중에 두 오더 번호를 모두 포함하는 ORU^R01으로 반환됩니다.
수신 시스템은 두 번 응답합니다. 즉시, 메시지가 수신 및 파싱되었음을 확인하는 ACK(MSA-1 AA 수락, AE 오류, AR 거부)으로 응답합니다. 그런 다음 애플리케이션 응답으로, ORR^O02(ORM용) 또는 ORL^O22(OML용)를 보내 ORC를 OK 또는 UA로 반복하고 ORC-3인 수행자 오더 번호를 채웁니다. 이 번호는 양측에서 이후에 사용됩니다. 결과는 ORU^R01로 반환되며, OBR-2 및 OBR-3에 동일한 의뢰자 및 수행자 번호가 포함되어 결과가 해당 오더를 찾을 수 있도록 합니다. HL7 v2 메시지 설명: ADT 및 ORU를 참조하십시오.
오더 오류 발생 지점
HL7 v2 오더는 대부분 플레서와 필러 번호 불일치(ORR이 처리되지 않은 경우), OBR-4의 LOINC 코드 없는 로컬 검사 코드, 원본 플레서 번호 없이 전송된 취소, SPM 세그먼트가 2.3.1 수신자에게 전송된 경우와 같은 버전 불일치, 그리고 ORC-7 또는 OBR-5 대신 자유 텍스트 NTE에 기록된 우선순위로 인해 오류가 발생합니다.
- 일치하지 않는 번호: ORU가 EHR에서 본 적 없는 수행자 번호로 반환되는 경우, 이는 일반적으로 ORR이 처리되지 않았기 때문입니다.
- OBR-4의 로컬 코드: LOINC 코드 대신 (또는 없이) 검사실의 내부 검사 코드를 사용하는 경우, 수신 기록에서 검사를 매핑할 수 없습니다. 해결책은 두 가지 코드를 모두 사용하는 것입니다:
GLU^Glucose^L~2345-7^Glucose [Mass/volume] in Serum or Plasma^LN. - 원본 번호 없는 취소:
CA는 취소하려는 오더의 의뢰자 번호를 포함해야 합니다. - 버전 불일치: 2.3.1 수신자에게 SPM 세그먼트를 보내면 해당 세그먼트가 삭제되거나 거부됩니다.
- 잘못된 필드의 우선순위: ORC-7 또는 OBR-5 대신 자유 텍스트 NTE 필드에
STAT이 있는 경우.
FHIR에서의 동일한 오더
FHIR에서는 HL7 v2 오더의 ORC 및 OBR 세그먼트가 하나의 ServiceRequest로 통합됩니다. 여기에는 상태, 의도 오더, 우선순위, LOINC 코드, 대상, 진료, 요청자, 발생 일시, 진단 근거 코드 및 플레서와 필러 번호에 대한 식별자가 포함됩니다. 결과적인 Observation 및 DiagnosticReport는 HL7의 v2-to-FHIR 구현 가이드에서 매핑하는 방식에 따라 basedOn을 통해 이를 참조합니다.
FHIR에서는 ORC와 OBR이 하나의 ServiceRequest로 통합됩니다: status (active, on-hold, revoked, completed), intent (order), priority (routine, urgent, asap, stat), code (LOINC 검사), subject, encounter, requester, occurrenceDateTime, reasonCode (ICD-10 진단) 및 의뢰자/수행자 번호에 대한 identifier입니다. 결과 Observation 및 DiagnosticReport는 basedOn으로 다시 연결됩니다. HL7는 v2-to-FHIR 구현 가이드에서 필드별 매핑을 게시합니다.
Anpheros Platform은 ServiceRequest, Observation 및 DiagnosticReport를 지원하며, 랩 커넥터는 HL7 v2, CSV 또는 JSON 형식의 결과를 수락합니다. 오더를 보내거나 받지는 않으며, 오더는 병원 또는 검사실 시스템에 유지되고 완료된 결과는 환자의 기록에 추가됩니다.
관련 페이지
- HL7 v2 메시지 설명: ADT 및 ORU
- HL7 대 FHIR
- PACS 대 RIS 대 VNA
- 랩 커넥터: HL7 v2, CSV 또는 JSON을 FHIR로
- LOINC 코드는 무엇인가요?
- HL7 v2에서 FHIR로의 매핑 (개발자용)
- 검사실 정보 시스템을 EHR과 통합하는 방법
- 인터페이스 엔진 설명
출처
- HL7 Version 2 제품군
- HL7 v2.5.1 ORM_O01 참조 (Caristix)
- HL7 v2.5.1 OML_O21 참조 (Caristix)
- HL7 v2-to-FHIR 구현 가이드
- HL7 FHIR R4: ServiceRequest
- IHE Laboratory Testing Workflow (LTW)
자주 묻는 질문
ORC와 OBR의 차이점은 무엇인가요?
ORC는 행정적 객체로서의 오더에 관한 것입니다: 누가 의뢰했는지, 오더 번호, 상태, 우선순위. OBR은 요청된 서비스에 관한 것입니다: 어떤 검사인지, 어떤 검체인지, 언제인지. 모든 OBR 앞에는 해당 ORC가 옵니다.
의뢰자(placer)와 수행자(filler)는 무엇인가요?
의뢰자는 서비스를 요청하는 시스템(EHR 또는 의뢰 의사의 시스템)이고, 수행자는 서비스를 수행하는 시스템(검사실 또는 영상의학과 시스템)입니다. 각 시스템은 자체 오더 번호를 할당하며, 메시지에는 양측이 오더를 찾을 수 있도록 두 번호가 모두 포함됩니다.
새로운 검사실 인터페이스를 위해 ORM 또는 OML을 구현해야 하나요?
파트너가 2.5.1 버전 이상에서 OML^O21을 지원하는 경우, 이를 선호하십시오: 검체 처리가 명시적이고 IHE 프로파일이 이를 기반으로 구축됩니다. 파트너가 구형 LIS인 경우, ORM^O01을 사용하며 이에 맞춰 조정해야 합니다.
HL7 v2 오더는 FHIR에 어떻게 매핑되나요?
ORC와 OBR은 함께 ServiceRequest가 되며, 의뢰자 및 수행자 번호는 식별자가 됩니다. ORC-1 및 ORC-5는 상태로, OBR-4는 코드로, DG1은 reasonCode로, 주문한 의사는 requester로 매핑됩니다. HL7 v2-to-FHIR 가이드에는 상세한 테이블이 게시되어 있습니다.
샌드박스에서 무료로 사용해 보세요
5분 만에 첫 FHIR 호출. 환자의 동의가 내장된 HL7 FHIR R4 API: 샌드박스에서 먼저 사용해보고, 자체 앱 또는 병원 시스템을 연결하세요.
무료 · 합성 환자 30명 · 카드 불필요
Anpheros는 환자가 직접 관리하고 어떤 병원과도 공유할 수 있는 의료 기록을 EU 기반의 HL7 FHIR R4 플랫폼에서 구축합니다. 이 가이드들은 건강 정보를 이해하고 정리하는 데 도움을 드리며, 의사의 진료를 대체하지 않습니다.
Anpheros 소개 →