문서 우선 openEHR 지속성 계층

임상 쿼리 제품군 통합

이 솔루션은 MongoDB에서 문서 우선 및 반평탄화 지속성 모델을 사용하여 해당 문제를 해결합니다. 반평탄화란 각 요소를 배열의 노드로 평면화하되 각 노드가 원래 구조의 전체 JSON 페이로드를 그대로 유지하는 방식을 의미합니다. 문서 우선이란 각 openEHR 컴포지션을 아키타입별 테이블이나 경로별 행으로 분해하지 않고 단일 MongoDB 문서로 보존하는 것을 뜻합니다. 동시에 컴포지션은 재구성 가능한 노드 배열로 구체화되므로 컴포지션이라는 운영 단위를 유지하면서도 효율적인 경로 기반 쿼리를 수행할 수 있습니다.

각 저장된 노드는 다음과 같은 주요 요소를 보유합니다.

• 로컬 임상 서브트리: 원래의 의미와 컨텍스트를 그대로 활용할 수 있습니다.

• 위치 메타데이터를 통해 구조와 순서를 재구성할 수 있습니다.

• 역방향 AQL 경로: 가변 깊이의 경로 제약 조건에 대해 효율적인 매칭을 가능하게 합니다.

역방향 경로는 개별 환자 단위 및 다수 환자 대상 실행 경로 모두에서 구조적 조건자를 효율적으로 평가하는 데 사용되는 일반 쿼리 키입니다. 이 키는 정규식 기반 매칭 및 검색 인덱스의 와일드카드 방식 경로 확인을 포함하여 다양한 실행 전략에서 경로 제약 매칭을 지원합니다. 조건자가 다른 텍스트 경로 구성 요소나 텍스트 조건을 사용하는 경우에도 동일한 쿼리 패턴을 적용할 수 있습니다.

이 모델을 사용하면 AQL 절을 MongoDB 쿼리 단계로 결정론적으로 컴파일할 수 있습니다. FROM, CONTAINS 및 WHERE 제약 조건은 노드 경로 및 값에 대한 타겟팅된 조건자가 됩니다. 이 접근 방식은 컴포지션을 기본 임상 컨테이너로 온전하게 유지하면서도 대규모 환경에서 운영 조회를 실용적으로 만들어 줍니다.

그림 1. 각 노드가 자체 컨텍스트 및 값과 역방향 AQL 경로를 포함하는 반평탄화된 컴포지션의 구조

워크로드 기반 라우팅

많은 리포지토리의 경우 단일 반평탄화 컬렉션과 와일드카드 인덱스만으로도 충분합니다. 더 큰 규모의 배포 환경에서는 광범위한 다수 환자 대상 필터링에 필요한 데이터만 포함하는 간소화된 검색 프로젝션을 사용할 수 있습니다. 이후 쿼리 실행은 범위에 따라 라우팅됩니다. 간소화된 검색 프로젝션은 광범위한 다수 환자 대상 필터링에 필수적인 노드 필드만 저장하는 소규모 파생 컬렉션입니다. 이는 메인 컴포지션 문서를 대체하지 않으며 광범위한 운영 쿼리의 인덱스 폭과 검색 비용을 절감합니다.

이에 따라 다음과 같은 실행 방식을 제공합니다.

• 개별 환자 단위 쿼리는 ehr_id 및 reversed_path 필드에 대한 복합 인덱스와 같은 타겟 인덱스를 사용하여 메인 컴포지션 컬렉션에서 실행됩니다.

• 다수 환자 대상 쿼리는 더 간소화된 프로젝션을 대상으로 실행되며 경로 제약 조건은 와일드카드나 역방향 경로 매칭으로, 값 조건자는 등호, 범위 또는 검색 연산자로 컴파일됩니다.

이 실행 모델은 단일 쿼리 인터페이스를 제공하며 워크로드 규모와 선택도에 따라 다양한 물리적 액세스 경로를 지원합니다.

운영 코호트 쿼리 지원이 중요한 이유

현대의 임상 애플리케이션은 동일한 플랫폼 내에서 두 가지 쿼리 패밀리를 모두 처리해야 하는 필요성이 증가하고 있습니다. 임상의는 특정 환자의 기록을 즉시 열람하는 동시에 다음과 같은 질문을 던질 수 있어야 합니다.

• 특정 기간 내에 특정 약물을 투여받은 환자는 누구인가?

• 어떤 환자가 프로토콜 또는 안전 규칙과 일치하나요?

• 현재 사례와 임상적으로 유사한 이전 사례는 무엇인가?

이러한 운영상의 질문은 반복적인 ETL 주기를 통해 데이터를 별도의 시스템으로 전송하지 않고도 답변을 얻을 수 있어야 합니다.

문서 우선의 반평탄화 모델은 openEHR의 강점을 유지하면서 이러한 워크로드를 실용적으로 구현할 수 있게 합니다. 이 모델은 컴포지션을 신뢰할 수 있는 운영 단위로 유지하고 재구성 가능한 구조를 통해 임상적 충실도를 보존하며, 애플리케이션 팀이 환자 중심 저장소와 별도의 다수 환자 대상 플랫폼 중 하나를 선택해야 하는 제약을 없애줍니다. 규모가 작은 리포지토리는 단일 반평탄 컬렉션을 사용하여 단순하게 구성할 수 있습니다. 규모가 큰 리포지토리의 경우 소규모 프로젝션을 추가하여 광범위한 운영 필터링에 드는 비용을 절감할 수 있습니다.

본 평가 결과 이 접근 방식은 대규모 환경에서도 개별 환자 단위 및 다수 환자 대상 쿼리 모두에서 빠른 응답 시간을 기록하며 두 워크로드 유형 전반에 걸쳐 낮은 엔드 투 엔드 지연 시간을 유지했습니다. 이러한 효율성은 단일 플랫폼에서 운영 검색, 출처 인식 처리, 시맨틱 강화 및 AI 기반 워크로드를 지원해야 하는 openEHR 리포지토리에 있어 실용적인 기반임을 입증합니다.

문서 우선 임상 데이터 전략을 위한 실험적 참조 런타임 및 툴킷인 KEhrnel을 사용하여 이 패턴을 탐색할 수 있습니다.

이 방식을 따르면 다음과 같은 실질적인 이점을 얻을 수 있습니다:

• 컴포지션 충실도를 보존하는 재구성 가능한 반평탄 모델

• 임상 문서를 관계형으로 파편화하지 않고도 효율적인 개별 환자 단위 쿼리 수행

• 웨어하우스 우선 아키텍처로 전환하지 않고도 환자 통합 운영 검색 지원

• 중복된 저장소와 분산된 로직 대신 애플리케이션 팀을 위한 단일 운영 쿼리 인터페이스 제공

• ETL 오버헤드 감소, 거버넌스 편차 완화 및 총 소유 비용 절감 경로 확보

Kehrnel의 정의와 사용 목적

Kehrnel은 헬스케어 데이터 모델을 운영 역량으로 전환하는 전략형 런타임입니다. 헬스케어 데이터 모델을 정의하는 것만으로는 충분하지 않기에 Kehrnel이 존재합니다. 개발 팀에는 요구 사항의 변화에 따라 데이터를 검증하고 이를 운영 표현으로 변환하며 수집, 쿼리, 유지 관리 및 발전시킬 수 있는 반복 가능한 방법이 필요합니다. 이러한 실행 계층이 없다면 모델은 단순한 문서나 스토리지 스키마 또는 고립된 사양으로 남게 되는 경우가 많습니다.

목표는 단순한 openEHR 엔진 구축보다 광범위합니다. Kehrnel은 헬스케어 데이터 모델을 API, 툴링 및 AI 워크플로 전반에서 실행, 검사 및 재사용이 가능하도록 만드는 반복 가능한 문서 우선 접근 방식을 제공합니다. 시간이 지남에 따라 동일한 런타임 패턴을 통해 FHIR, 합성 데이터 워크플로, 시맨틱 카탈로그, 자연어 검색 및 기타 도메인 전용 도구를 포함한 다양한 모델 계열 및 운영 전략을 지원할 수 있습니다.

Kehrnel은 각 지속성 전략의 요구 사항에 따라 맞춤 설정이 가능한 노출형 워크플로를 기반으로 설계되었습니다. 각 전략은 일관적인 런타임 모델을 유지하면서 자체 활성화, 유효성 검사, 수집, 변환, 쿼리, 합성 데이터 및 유지 관리 작업을 독자적으로 정의할 수 있습니다.

Kehrnel이 openEHR을 시작점으로 채택한 이유는 openEHR이 요구 사항이 까다롭고 시맨틱이 풍부한 모델이기 때문입니다. 여기에는 아키타입, 템플릿, 경로, 용어 및 복잡한 쿼리 동작이 포함됩니다. 따라서 이는 모델 기반 런타임 접근 방식을 입증하기 위한 강력한 토대가 됩니다.

본 솔루션에서 Kehrnel은 문서 우선 지속성 패턴을 위한 참조 런타임 및 툴킷 역할을 합니다.

그림 2. Kehrnel CLI 스크린샷

이 문서를 읽는 방법

하나의 MongoDB 문서는 하나의 OpenEHR 컴포지션을 나타냅니다. cn 배열에는 해당 컴포지션에서 추출된 쿼리 가능한 노드가 저장됩니다. 각 노드는 원래 구조를 재구성할 수 있도록 data에는 로컬 임상 서브트리를, p에는 역방향 경로 키를 그리고 kp, pi, bk와 같은 위치 메타데이터를 유지합니다.

공개 예시에서는 변환 과정을 더 쉽게 이해할 수 있도록 읽기 쉬운 형식으로 경로 키를 보여줍니다. 실제 운영 환경에서는 경로 크기와 인덱스 설치 공간을 줄이기 위해 동일한 경로를 간결한 사전 인코딩된 토큰으로 저장할 수 있습니다.

역방향 경로 인코딩

저장된 경로 필드는 키 최적화를 나타냅니다. 참조 모델 속성과 아키타입 노드 식별자는 openEHR 경로를 구축합니다. 이 솔루션은 역방향으로 저장된 경로를 사용하여 리딩 와일드카드 스캔 대신 접두사 친화적 매칭으로 포함 제약 조건을 평가할 수 있게 합니다 이 설정은 개별 환자 단위 경로에서의 표준 정규식 기반 매칭 및 검색 경로에서의 와일드카드 방식 매칭과 함께 작동합니다.

결정론적 AQL-MQL 변환

AQL은 저장 모델과 독립적이므로 결정론적 컴파일이 효과적으로 작동합니다. SQL 절은 다음과 같이 MQL로 변환됩니다.

• FROM 및 CONTAINS는 구조적 경로 조건자가 됩니다.

• WHERE 은 일치하는 노드 페이로드에서 값 조건자가 됩니다.

• SELECT 는 프로젝션이 됩니다.

• ORDER BY 는 정렬이 됩니다.

다음 예시는 AQL 쿼리를 설명합니다.

SELECT
  e/ehr_id/value AS ehrId,
  c/uid/value AS compositionId,
  med_ac/description[at0017]/items[at0140]/items[at0141]/value/defining_code/code_string AS locationCode
FROM
  EHR e
  CONTAINS COMPOSITION c[openEHR-EHR-COMPOSITION.vaccination_list.v0]
  CONTAINS (
    CLUSTER adminInfo[openEHR-EHR-CLUSTER.admin_salut.v0]
    AND SECTION[openEHR-EHR-SECTION.immunisation_list.v0]
    AND ACTION med_ac[openEHR-EHR-ACTION.medication.v1]
  )
WHERE
  med_ac/time/value >= '2000-04-13T07:54:16.345Z'
  AND med_ac/time/value <= '2026-02-13T07:54:16.345Z'
  AND adminInfo/items[at0007]/items[at0014]/value/defining_code/code_string = 'E08019820'
  AND med_ac/other_participations/performer/identifiers/id = '038321545'
ORDER BY
  med_ac/time/value DESC

AQL 쿼리의 의도

이 쿼리는 구조적 제약 조건과 값 기반 제약 조건을 결합합니다. CONTAINS 절은 필요한 openEHR 구조를 정의하며 이 경우 관리 클러스터와 투약 작업을 포함하는 예방 접종 컴포지션을 정의합니다. 그런 다음 WHERE 절에서 행위 시간, 수행자 식별자 및 관리 코드에 대한 조건자를 추가합니다.

이러한 쿼리 유형은 결정론적 컴파일에 유리합니다. 이는 계층적 임상 구조와 노드 로컬 값에 대한 조건을 표현합니다.

컴파일러가 AQL을 MQL에 매핑하는 방법

컴파일된 MQL은 AQL과 동일한 로직을 따릅니다.

• 최상위 ehr_id 필터는 쿼리를 환자 범위로 만듭니다.

• $all 절은 AQL에 기술된 모든 구조적 브랜치가 동일한 컴포지션에 포함되도록 요구합니다.

• 각각의 $elemMatch는 경로 조건자와 해당 값 조건자들을 동일한 저장 노드에 바인딩합니다.

• p의 조건자는 구조적 CONTAINS 로직이 컴파일된 형태입니다.

• 데이터 하위의 조건자들은 WHERE 조건이 컴파일된 형태를 나타냅니다.

• 전체 파이프라인에서 컴파일러는 SELECT 및 ORDER BY에 해당하는 프로젝션 및 정렬 단계를 추가합니다.

다음 예시는 위의 AQL 쿼리에서 생성된 간소화된 개별 환자 단위 MQL 패턴을 보여줍니다. 이는 컴파일러 로직을 설명하기 위한 것이며 실제 런타임 페이로드와 바이트 단위로 일치하는 것은 아닙니다.

// Simplified compiler output for a single-EHR query.
// Projection and sorting stages are omitted here for clarity.
db.compositions.aggregate([
   {
      "$match": {
         "ehr_id": "b416bc97-de39-43f5-9d47-712af6688947~r1",
         "cn": {
            "$all": [
               {
                  "$elemMatch": {
                     "p": {
                        "$regex": /^ACTION\.medication\.v1(?:\.[^.]+)*\.SECTION\.immunisation_list\.v0(?:\.[^.]+)*\.COMPOSITION\.vaccination_list\.v0$/
                     },
                     "data.time.value": {
                        "$gte": ISODate("2000-04-13T07:54:16.345Z"),
                        "$lte": ISODate("2026-02-13T07:54:16.345Z")
                     },
                     "data.other_participations.performer.identifiers.id": "038321545"
                  }
               },
               {
                  "$elemMatch": {
                     "p": {
                        "$regex": /^at0014\.at0007\.CLUSTER\.admin_salut\.v0(?:\.[^.]+)*\.COMPOSITION\.vaccination_list\.v0$/
                     },
                     "data.value.defining_code.code_string": "E08019820"
                  }
               }
            ]
         }
      }
   }
]);

동일한 로직이 검색 경로로 이동하는 방법

다수 환자 대상 경로에서도 논리적 변환 방식은 동일하게 유지됩니다. 차이점은 물리적 실행 방식에 있습니다. 컴파일러는 메인 컴포지션 컬렉션에서 매칭하는 대신 간소화된 검색 프로젝션을 대상으로 합니다. 역방향 경로의 구조적 제약은 와일드카드 필터가 되고 값 조건자는 범위 및 동등 필터가 됩니다.

다음 예시는 특정 환자에 종속되지 않은 AQL에서 생성된 MQL 패턴을 보여줍니다. 이전과 마찬가지로, 이는 컴파일러 로직을 설명하는 것이며 실제 런타임 페이로드와 바이트 단위로 일치하는 것은 아닙니다.

{
   "$search": {
      "index": "search_nodes_index",
      "compound": {
         "filter": [
            {
               "embeddedDocument": {
                  "path": "sn",
                  "operator": {
                     "compound": {
                        "filter": [
                           {
                              "wildcard": {
                                 "path": "sn.p",
                                 "query": "ACTION.medication.v1*SECTION.immunisation_list.v0*COMPOSITION.vaccination_list.v0"
                              }
                           },
                           {
                              "range": {
                                 "path": "sn.data.time.value",
                                 "gte": ISODate("2000-04-13T07:54:16.345Z"),
                                 "lte": ISODate("2025-04-13T07:54:16.345Z")
                              }
                           },
                           {
                              "equals": {
                                 "path": "sn.data.other_participations.performer.identifiers.id",
                                 "value": "038321545"
                              }
                           }
                        ]
                     }
                  }
               }
            }
         ]
      }
   }
}

반복되는 구조와 동일 경로 상의 형제 노드

일부 openEHR 구조는 유효 경로가 동일한 반복되는 형제 노드를 포함할 수 있습니다(예: 반복되는 EVENTs). 이러한 경우 컴파일러는 동일한 반복 항목이 조건을 충족할 수 있도록 조건자를 더 깊은 단계로 중첩해야 합니다. 표준 집계에서는 이는 더 깊게 중첩된 $elemMatch로 처리합니다. 검색 경로에서 이와 동등한 기능은 여러 조건을 동일한 내장 배열 요소에 바인딩하는 embeddedDocument입니다.