I.

메타데이터 기반의 HL7 메시지 검증 모듈의 설계 및 구현

Design and Implementtion of a metadata based HL7 message validation module

Jin-Tae Song*, Il-Kon Kim*

* Department of Computer Science, Kyungpook National University

Abstract: In order to validate a HL7 message in a medical related application on various platform, you need a HL7 message validation module. We developed a HL7 message validation module taht is available on various platform, because it is developed by ANSI C++. This module uses a metadata that includes regular expressions and data about HL7 message structure. Also, we are developing an application to modify a metadata. So, this module is usable on various domain.

Keyword: HL7, Validation, Regular Expression, HL7 Database

배 경

병원에서의 전자문서화가 활발히 보급되면서, 의료 데이터가 전송되는 경우가 빈번해졌다. 그에 따라, 전송되는 데이터가 HL7 표준을 따르는지를 검증해야 하는 경우도 함께 증가하게 되었다. 그러므로, HL7 메시지의 검증을 위한 모듈이 필요하며 특히, 플랫폼간의 이식성이 좋으며, 도메인에 따라 수정이 가능한 검증 모듈이 필요하게 되었다.

II. HL7 메시지의 구조

본 섹션에서는 HL7 메시지가 가지는 계층적 구조와 이를  RDB상에 표현하고 있는 HL7 DB의 구조에 대해서 알아보도록 한다.

1. HL7 메시지의 계층적 구조

HL7 메시지는 <그림 1>과 같이 메시지, 세그먼트, 필드, 콤포넌트, 서브 콤포넌트로 이루어진 계층 구조를 가진다.

그림 1 - HL7 메시지의 구조

하나의 HL7 메시지가 가지는 세그먼트는 적게는 2개의 세그먼트에서 많게는 수십개 이상의 세그먼트로 이루어진다. 또한 하나의 세그먼트도 적게는 1개의 필드에서 많게는 수십개 이상의 필드로 이루어진다. 이러한 1:N 관계로 인해서 트리구조의 최하위 노드인 SubComponent 단계가 되면 그 숫자는 폭발적으로 증가하게 된다.

이러한 트리 구조의 HL7메시지를 검증함에 있어서 다음과 같은 검증 부분이 필요하다.

1.각 값이 데이터 타입에 맞는지를 검증.

2.Message의 타입에 따른 Segment의 배열을 검증.

3.Required 필드에 대한 값의 존재 여부를 검증.

4.필드 값의 길이를 검증.

위와 같은 검증을 위해서는 각 HL7 메시지의 구조에 대한 정보가 필요하며, 이러한 정보를 저장하고 있는 HL7 데이터베이스에 대한 이해가 필요하다

2.  HL7 메시지 구조 정보 데이터베이스의 구조

HL7 메시지의 계층적 구조를 RDB에 저장하기 위해서 HL7 DB에는 <그림 2>와 같은 여러 테이블이 존재하며, 각 테이블의 연관관계를 통해서 <그림 1>의 1:N 관계를 표현한다. 예를 들어, Segment 와 Field의 관계는 SegmentDataElements 테이블에 의해서 표현되는데, <그림 3>과 같이 하나의 seg_code를 가지는 여러 data_item이 존재한다. 이를 통해 1:N의 관계가 저장된다.

그림  - HL7 구조 데이터 베이스의 각 테이블간의 연관관계

그림 3 - SegmentDataElements 테이블의 구조

위와 같이 HL7 메시지의 구조 정보를 저장하는 HL7 DB를 이용하면 HL7 메시지를 정확하게 검증할 수 있다. 하지만 몇가지 문제점이 존재한다.

1.데이터베이스와의 연결이 필요하므로 데이터베이스에 대한 관련 모듈들이 필요하다.

2.검증시에 구조 정보를 읽기 위해서 데이터 베이스에 질의를 해야하고 결과를 반환해야 하므로, 그에 따른 부가적인 시간이 소요된다.

3.검증에 필요하지 않은 테이블도 포함하므로 검증 모듈의 크기가 커진다.

4.검증 모듈에 데이터베이스 파일을 포함해야 하므로, 모듈의 크기가 커진다.

이러한 단점을 극복하기 위해서 HL7 DB의 여러 테이블중에서 검증에 필요한 테이블만을 조합하여 검증에 바로 사용할 수 있는 메타데이터를 생성하여 검증 모듈에 적용하는 방법을 제안한다.

III. 메타데이타의 구조

메타데이터는 앞서 언급한 메시지 검증의 각 부분에 필요한 정보만으로 구성된다. 각 메타데이터는 1 줄 단위이며, : 기준으로 Key와 Value로 구분된다.

1. 세그먼트의 배열 검증을 위한 메타데이터

세그먼트의 배열을 결정하는 메시지 구조 ID와 세그먼트의 배열 정보로 이루어진다. 세그먼트 배열 정보는 MsgStructIDSegments 테이블의 값들을 조합하여 정규 표현식의 형태로 저장한다. ? 는 세그먼트의 Optional을 의미하며, *는 Optional Repeat를 의미하며, +는 Required Repeat를 의미한다. 또한 괄호를 이용하여 세그먼트 그룹을 설정한다.

ADT_A09:^(MSH)(EVN)(PID)(PD1)?(PV1)(PV2)?(DB1)*(OBX)*(DG1)$

2.  필드 속성 검증을 위한 메타데이터

각 필드의 속성 검증을 위한 메타데이터는 SegmentsDataElements 테이블의 정보를 조합하여 구성된다. 이 데이터는 길이, Required/Optional, Repeat, 데이터 타입에 대한 정보를 모두 가지기 때문에 정규표현식만으로는 표현할 수 없으므로, 이러한 정보를 표현할 수 있는 임의의 구조를 생성하여 저장한다. 예를 들어, RN^18^2는 다음과 같은 의미를 가진다. 반드시 값을 가져야 하는 Required 필드이며, 반복은 되지 않는다. 데이터아이템 번호는 18번이며, 길이는 2이다.  각 필드는 HL7 표준의 필드 구분자를 이용하여 구분된다. 데이터 아이템 번호는 3.4의 메타데이터의 Key로 이용되나.

MSA:RN^18^2|RN^10^20|ON^20^80|ON^21^15|BN^22^1|ON^23^25

3.  데이터타입 검증을 위한 메타데이터

데이터 아이템 번호와 그 데이터 아이템의 구조를 SubComponent 단계까지 구분하여 저장한다. SubComponent 단계까지 구분하기 때문에, Component와 SubComponent의 구분을 위하여 HL7 표준의 Component 구분자와 SubComponent 구분자를 이용한다. 그리고, 괄호를 사용하여 테이블을 참조할 경우 그 테이블의 번호를 지정할 수 있다. 같은 데이터 타입이라도 사용되는 곳에 따라 적용되는 테이블 번호가 달라질 수 있다. 이를 처리하기 위해서 메타데이터를 위한 전처리 메타데이터를 두어서 처리한다. 전처리 메타데이터는 메시지 타입의 구조를 가지고 있으며, 상위단계에서 적용된 테이블 번호를 알맞은 Subcomponent에 적용시킬 수 있는 구조를 가지고 있다.

23:ID(357)^ST(0)^IS(396)^ST(0)^ST(0)^IS(396)

24:ST(0)^NM(0)^NM(0)^ID(0)&ST(0)&IS(396)&ST(0)&ST(0)&IS(396)

25:TS(0)

4.  테이블 값 검증을 위한 메타데이터

3.3에서 지정한 테이블 번호를 Key 값으로 사용하며 그 테이블 번호에 유효한 값들은 TableValues 테이블에서 생성되어 저장된다. 이 역시 정규표현식의 형태로 저장되기 때문에 검증시에 정규표현식 객체에 바로 적용될 수 있다. 테이블 값들중에는 숫자의 범위를 나타내는 값들도 있다. 이럴 경우에는 정규표현식의 범위 연산자를 사용하여 표현하면 처리 속도를 빠르게 할 수 있다.

1:F|M|O|U|A|N

2:A|D|M|S|W|C|G|P|R|E|N|I|B|U|O|T

5.  Primitive 데이터타입 검증을 위한 메타데이터

3.3에서 각 SubComponent로 구분된 값은 그 데이터 타입의 정규표현식과 연결되어 검증이 된다. IS/ID를 제외한 데이터 타입의 경우에는 검증을 위한 정규표현식으로 지정된다. 하지만 IS/ID의 경우에는 Table의 값을 참조해야 하므로, TABLE이라고 지정하며, ID와 같이 반드시 테이블 값을 참조해야 할 경우에는  TABLE! 로 지정한다.

ST:.*

IS:TABLE

ID:TABLE!

NM:^(\\+|-)?\\d+(\\.\\d{1,10})?

IV.  검증 모듈의 구조와 사용

1.  검증 모듈의 구조

검증 모듈은 크게 3개의 클래스로 이루어진다. 그리고 정규표현식을 이용하기 위하여 Boost 라이브러리를 사용하였다.

1.HITValidateResult

검증 결과를 표현하기 위한 클래스로써, HL7 Error Code와 HL7 Error Condition Text등을 멤버로 가지며, 검증 결과의 연산을 위해서 ==, + 와 같은 오퍼레이션 오버로딩이 구현된다.

2.HITMetaFile

앞서 살펴본 메타데이터를 파일로부터 읽어들여서 정규표현식 객체를 생성한 후, 이를 HashTable에 저장하고 있다. 원하는 정규표현식을 검색하여 반환 할 수 있는 GetRegEx() 함수를 제공한다.

3.HITValidate

입력된 메시지를 SubComponent 단계까지 분할하여 메타데이터를 이용하여 검증하고 결과는 HITValidateResult의 형태로 반환한다.

2.  검증 모듈의 사용

원하는 메타데이터를 설정하여 HITValidate에 적용한 후, Validate() 함수를 호출함으로써 메시지에 대한 검증 결과를 얻을 수 있다. 또한 HITValidate 객체에 다른 메타데이터를 적용할 수 있으므로, 하나의 메시지에 대해서 여러 메타데이터를 적용하여 검증 할 수 있다. 그러므로, 하나의 메시지라도 다양한 도메인에 대해서 검증을 할 수 있다.

그림  - 검증 모듈의 사용

V.  결론

본 검증 모듈은 HL7 메시지가 표준에 맞는지를 쉽게 검증 할 수 있도록 해 주며, 표준 C++로 작성되었기 때문에, 시스템 이식성이 높다. 또한 사용자가 쉽게 메타데이터를 수정 할 수 있는 어플리케이션이 개발중이므로 다양한 도메인에 쉽게 적용될 수 있다.

VI. 참고문헌

1. Development of Prototype for Exchang Discharge Summary Information between two University Hospitals using HL7, Ki Sung Um, Yun Sik Kwak, Hune Cho, Hee-Seung Bom, Il Kon Kim, Bockgyun Lee

2. Estimate of Total Volume of Medical Data in a Year in Japan, Hiroshi Nagata, Hiroshi Tanak

3. Health Level Seven Standard version 2.4, Health Level Seven, 2000

4. Health Level Seven Standard version 2.5, Health Level Seven, 2003