문서 우선 openEHR 지속성 계층

임상 쿼리 제품군 조정

이 솔루션은 MongoDB 에서 문서 우선, 반 평면화된 지속성 모델을 통해 이러한 문제를 해결합니다. 반 평면화 는 각 요소를 배열 의 노드 로 평면화하지만 각각이 원래 구조의 전체 JSON 페이로드를 유지한다는 의미입니다. 문서 우선은 각 openEHR 구성이 아키텍처당 하나의 테이블이나 경로당 하나의 행으로 분해되지 않고 하나의 MongoDB 문서 로 보존됨을 의미합니다. 동시에 구성은 재구성 가능한 노드 배열 로 구체화되어 운영 단위인 구성을 포기하지 않고도 효율적인 경로 기반 쿼리를 가능하게 합니다.

각 저장된 노드 다음과 같은 키 요소를 유지합니다.

• 로컬 임상 하위 트리이므로 원래의 의미와 컨텍스트를 계속 사용할 수 있습니다.

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

• 역 AQL 경로로 가변 깊이 경로 제약 조건을 효율적으로 일치시킬 수 있습니다.

역방향 경로는 환자 범위 및 교차 환자 실행 경로 모두에서 구조적 조건자를 효율적으로 평가하는 데 사용되는 일반 쿼리 키입니다. 검색 인덱스의 정규식 기반 일치 및 와일드카드 스타일 경로 확인을 포함하여 다양한 실행 전략에서 경로가 제한된 일치를 지원합니다. 조건자가 다른 텍스트 경로 구성 요소 또는 텍스트 조건을 사용할 때 동일한 쿼리 패턴을 적용할 수 있습니다.

이 모델을 사용하면 AQL 절을 MongoDB 쿼리 단계로 결정론적으로 컴파일할 수 있습니다. FROM, CONTAINS 및 WHERE 제약 조건은 노드 경로 및 값에 대한 대상 조건자가 됩니다. 이 접근 방식은 구성을 프라이머리 임상 컨테이너 로 그대로 유지하면서 확장하다 운영 검색을 실용적으로 만듭니다.

그림 1. 각 노드 고유한 컨텍스트와 값과 반전된 AQL 경로를 전달하는 반평면화된 구성을 나타냅니다.

워크로드별 라우팅

많은 리포지토리의 경우 반 평면화된 단일 컬렉션 과 와일카드 인덱스로 충분합니다. 대규모 배포의 경우 이 모델은 광범위한 환자 간 필터링에 필요한 데이터만 포함하는 슬림 검색 프로젝션 사용할 수 있습니다. 그러면 쿼리 실행이 범위별로 라우팅됩니다. 슬림 검색 프로젝션 은 광범위한 환자 간 필터링에 필요한 노드 필드만 저장하는 더 작은 파생 컬렉션 입니다. 기본 구성 문서 대체하지 않습니다. 광범위한 운영 쿼리에 대한 인덱스 범위와 검색 비용 줄입니다.

따라서 다음과 같은 양식을 제공합니다.

• 환자 범위 쿼리는 ehr_id 및 reversed_path와 같은 필드에 대한 복합 인덱스 와 같은 대상 인덱스를 사용하여 기본 구성 컬렉션 에서 실행 .

• 교차 환자 쿼리는 더 슬림해진 프로젝션, 컴파일 경로 제약 조건을 와일드카드 또는 역경로의 일치 항목으로, 값 술어를 동등성, 범위 또는 검색 연산자로 실행 .

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

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

최신 의료 애플리케이션은 동일한 플랫폼에서 두 쿼리 제품군을 모두 필요로 하는 경우가 증가하고 있습니다. 의사는 하나의 환자 기록 즉시 열어 다음과 같은 질문을 해야 할 수 있습니다.

• 어떤 환자가 주어진 창 동안 특정 약을 받았습니까?

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

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

이러한 운영 관련 질문에는 반복적인 ETL 주기를 통해 데이터를 별도의 시스템으로 푸시하지 않고 답변이 필요합니다.

문서 우선, 반 평면화 모델은 openEHR의 장점을 보존하고 이러한 워크로드를 실용적으로 만듭니다. 구성을 신뢰할 수 있는 운영 단위로 유지하고, 재구성 가능한 구조를 통해 의료 충실도를 보존하며, 애플리케이션 팀이 환자 중심의 저장 와 별도의 교차 환자 플랫폼 중에서 선택해야 하는 상황을 방지합니다. 더 작은 리포지토리는 하나의 반 평면화된 컬렉션 으로 간단하게 유지할 수 있습니다. 리포지토리가 클수록 프로젝션 더 작게 추가하여 광범위한 운영 필터링 비용 줄일 수 있습니다.

평가 결과, 이 접근 방식은 두 워크로드 유형 모두에서 낮은 엔드 투 엔드 지연 시간 유지했으며, 확장하다 에서도 환자 범위 및 교차 환자 쿼리에 대한 응답 시간이 짧습니다. 이러한 효율성 단일 플랫폼에서 운영 검색, 출처 인식 처리, 시맨틱 강화 및 AI 기반 워크플로를 지원 해야 하는 openEHR 리포지토리의 실용적인 기반으로 검증되었습니다.

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

이 접근 방식을 따르면 다음과 같은 실질적인 이점이 있습니다.

• 구성 충실도를 유지하는 재구성 가능한 반 평면화된 모델입니다.

• 임상 문서 의 관계형 파쇄를 강제하지 않고 효율적인 환자 범위 쿼리 .

• 창고 우선 아키텍처를 기본값으로 사용하지 않고 교차 환자 운영 조회를 지원합니다.

• 중복된 저장소와 조각난 로직 대신 애플리케이션 팀을 위한 하나의 운영 쿼리 표면입니다.

• ETL 오버헤드 줄이고, 거버넌스 드리프트를 줄이고, 총 소유 비용 줄일 수 있는 방법입니다.

Kernel이란 무엇이며 왜 사용하나요?

Kernel은 의료 데이터 모델을 운영 기능으로 전환하는 전략 런타임입니다. Kernel이 존재하는 이유는 의료 데이터 모델 정의하는 것만으로는 충분하지 않기 때문입니다. 또한 팀에는 데이터의 유효성을 검사하고, 데이터를 운영 표현으로 변환하고, 수집하고, 쿼리 , 유지 관리하고, 요구 사항 변경에 따라 발전시키는 반복 가능한 방법이 필요합니다. 해당 실행 계층이 없으면 모델은 문서, 저장 스키마 또는 격리된 사양으로 남아 있는 경우가 많습니다.

목표는 openEHR 엔진 구축하는 것보다 더 광범위합니다. Kernel은 API, 도구, AI 워크플로에서 의료 데이터 모델을 실행하고, 검사하고, 재사용할 수 있도록 반복 가능한 문서 우선 접근 방식을 제공합니다. 시간이 지남에 따라 동일한 런타임 패턴 FHIR, 합성 데이터 워크플로, 시맨틱 카탈로그, 언어 검색 및 기타 도메인별 도구를 포함한 다른 모델 군 및 운영 전략을 지원 수 있습니다.

Kernel은 각 지속성 전략의 요구 사항에 맞게 사용자 지정할 수 있는 노출된 워크플로를 중심으로 설계되었습니다. 각 전략은 일관적인 런타임 모델을 사용하면서 고유한 활성화, 유효성 검사, 수집, 변환, 쿼리 , 합성 데이터 및 유지 관리 작업을 정의할 수 있습니다.

openEHR은 까다롭고 시맨틱이 풍부한 모델이기 때문에 Kernel은 openEHR로 시작합니다. 여기에는 아키타입, 템플릿, 경로, 용어 및 복잡한 쿼리 동작이 포함됩니다. 이는 모델 기반 런타임 접근 방식을 증명하기 위한 강력한 기반이 됩니다.

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

그림 2. Kernel 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이며, 이는 여러 조건을 동일한 내장된 배열 요소에 바인딩합니다.