진료 공백 감지를 위한 임상 의사 결정 지원

MongoDB Atlas: 주요 역량

복잡한 헬스케어 워크로드에 적합하도록 설계된 MongoDB Atlas는 레거시 시스템을 고도로 최적화된 네이티브 데이터 에코시스템으로 대체합니다. 다음은 플랫폼이 실시간 의사 결정 지원을 제공할 수 있도록 하는 주요 기능에 대한 개요입니다.

그림 3. Atlas 주요 역량

유연한 document model: patient_360 collection 은 단일 문서에 완전한 환자 기록을 저장합니다—인구 통계, 질병, 약물, 검사, 활력 요약, 진료 결손, 경고, 개인 별 임계값 및 데이터 출처를 포함하여 단일 문서는 FHIR 저장에 대한 다중 리소스 조인이 필요한 질문에 답변합니다.

Time Series 컬렉션: synthetic_vitals 컬렉션은 MongoDB의 네이티브 time series 컬렉션을 사용하여 웨어러블 기기 데이터를 저장합니다. 이러한 컬렉션은 자동 데이터 버킷팅, 효율적인 범위 쿼리 및 고주파수 시계열 데이터를 위한 특수 빌드 저장소를 제공합니다.

변경 스트림: 플랫폼은 변경 스트림을 사용하여 실시간으로 새로운 중요 정보에 대응합니다. 독서가 도착하면 시스템은 CDS 규칙을 평가하고 폴링 없이 임상 경고를 생성합니다.

Queryable Encryption: MongoDB Queryable Encryption은 유휴 시 민감한 환자 필드를 보호합니다. 애플리케이션은 암호화된 PHI 필드를 평문으로 노출하지 않고 쿼리하여 HIPAA 요구 사항을 충족하고 별도의 암호화 계층이 필요 없습니다.

집계 파이프라인: 이 프레임워크는 대시보드 집계, 케어 갭 계산, 활력 징후 추세 분석 및 HEDIS 점수 산정을 처리하며 복잡한 임상 쿼리를 밀리초 단위로 해결합니다.

AI 및 분석을 위한 구조: patient_360 문서는 추가 변환 없이 정규화된 임상 사실, 구조화된 증거 및 메타데이터 출처를 하위 AI 및 분석 파이프라인에 전달합니다.

데이터 생성 파이프라인

초기화 시 이 솔루션은 다단계 파이프라인을 사용하여 CDS 시스템을 시딧하고 활성화합니다. 이는 아래에 설명되어 있습니다.

그림 4. 데이터 생성 파이프라인

데이터 생성 파이프라인은 초기화 시큰스를 진행합니다. 이 시큰스는 합성 및 구체화된 임상 데이터를 생성하고, 개인화된 임계값과 캐어 갥을 계산하며, 실시간 모니터링을 시작합니다. 파이프라인은 다음과 같이 작동합니다.

1. FHIR 환자 번들 생성: 조건, 약물, 검사 결과, 진료 및 알레르기를 포함하여 FHIR R4 트랜잭션 번들을 만듭니다. 이러한 번들은 상호 운영 계층 역할을 하는 FHIR 데이터 저장소에 저장됩니다.

2. 중요 사항 기록 생성: 환자별 중요 사항의 24시간 Time Series를 생성하여 정상, 악화 또는 급성 생리 패턴을 나타냅니다. 데이터를 synthetic_vitals Time Series 컬렉션에 저장합니다.

3. patient_360 문서 구현: 각 FHIR 번들을 MongoDB Atlas의 데노르말라이즈된 patient_360 문서로 변환합니다. 변환에는 소스 FHIR 기록으로 링크되는 data_provenance 블록이 포함됩니다.

4. 시드 CDS 규칙: 임상 결정 지원 규칙 정의를 cds_rules 컬렉션에 삽입합니다.

5. 개인화된 임계값 계산: 활성 약물 및 질환을 기반으로 환자별 바이털 사인 임계값을 계산합니다. 이 결과를 patient_360 문서에 저장합니다.

6. CDS 규칙 평가: AlertEngine 을 현재 바이털에 대해 실행하고 생성된 경고를 alerts 컬렉션에 쓰기합니다.

7. HEDIS 캐어 갭을 계산합니다. 각 환자의 임상 기록에 대해 QualityEngine 를 실행하고 구조화된 캐어 갭 결과를 patient_360 문서에 쓰기합니다.

8. 시드 제공자 속성: attributions 컬렉션에서 제공자-환자 속성 관계를 생성하여 누락 결과 및 경고를 받을 제공자를 결정합니다.

9. 실시간 모니터링 시작: 중요 시뮬레이션 워커를 활성화하고 서버 전송 이벤트를 통해 실시간 중요 사인 데이터를 임상 플랫폼으로 스트리밍하기 시작합니다.

CDS 엔진

CDS 엔진은 환자 데이터를 분석하여 캐어 팀에 대한 실행 가능한 인사이트를 제공합니다. 이 솔루션은 임상 모니터링과 품질 측정 계산을 두 개의 독립적인 엔진으로 분리합니다. 이 아키텍처 패턴은 실시간 경고 및 HEDIS 갥 노리를 분리하도록 권장하는 진료 상호 운영성을 위한 HL7 FHIR 가속 프로그램인 Da Vinci 이니시어티브를 준수합니다.

캐어 걁 워크플로

캐어 갥갑 워크플로는 헬스케어 조직이 환자의 실제 임상 캐어와 설정된 의료 지침 간의 불일치를 식별하고, 추적하고, 해결하는 데 사용하는 체계적 프로세스로 제공됩니다. 캐어 갥갑 감지는 식별에서 해결까지 다음 조치로 구성된 구조화된 경로를 따릅니다.

• 평가: QualityEngine 는 HEDIS 측정 기준에 대핕 각 환자의 임상 기록을 평가합니다.

• 쓰기 (write): 시스템은 지원 증거, 권장 조치 및 우선 순위와 함께 열린 갤를 patient_360 문서에 쓰기 (write)합니다.

• 검토: 케어 코디네이터는 우선 순위와 연체 기간으로 정렬된 임상 플랫폼의 미해결 갭갑을 검토합니다.

• 개입: KED 및 CDC-HBA와 같은 실행 가능한 개입 간격의 경우 플랫폼은 구조화된 개입 작업 공간을 열어 조정자가 실험실에 주문하거나 완료를 기록하거나 후속 조치를 예정합니다.

• 닫기: intervention이 완료되면 patient_360 문서에서 gap status가 업데이트되고 QualityEngine 이 다음 cycle에서 재평가됩니다.

• 에스칼레이션: AlertEngine 이(가) 임상 경고를 감지하면 관련 미결 갭의 우선 순위를 높이고 캐어 팀에 알림을 보냅니다. 팩시스 경고와 같이 관련 갭이 없는 경고는 독립적인 임상 알림으로 캐어 팀에 직접 전송됩니다.

문서 배열로서의 임상 데이터

patient_360 문서에서 각 조건은 conditions 배열의 항목을 나타내고, 각 약물은 medications 배열의 항목을 나타냅니다. 아래에 나와 있는 것처럼 문서는 별도 테이블에 걸쳐 저장되는 대신 사용되는 형태로 임상 개체를 저장합니다.

{
   "conditions": [
      {
         "code": "44054006",
         "display": "Type 2 diabetes mellitus",
         "clinical_status": "active",
         "onset_date": "2017-10-21T21:29:59.716351+00:00"
      },
      {
         "code": "433144002",
         "display": "Chronic kidney disease stage 3",
         "clinical_status": "active",
         "onset_date": "2023-09-12T21:29:59.716372+00:00"
      }
   ],
   "medications": [
      {
         "display": "Insulin glargine 100 units/mL injection",
         "dose": "20.0 units",
         "route": "subcutaneous",
         "frequency": "once daily at bedtime",
         "status": "active"
      },
      {
         "display": "Atenolol 50 mg oral tablet",
         "dose": "50.0 mg",
         "route": "oral",
         "frequency": "once daily",
         "status": "active"
      }
   ]
}

계산된 운영 필드

FHIR 번들에는 표준 상호 운영성 데이터가 포함되어 있지만 patient_360 문서에는 임상 플래그, 캐어 갭갑 결과, 개인화된 임계값 및 활성 경고를 포함하여 FHIR에서 정의하지 않는 운영 필드가 포함되어 있습니다.

예를 들어, 더 넓은 데이터 생성 파이프라인에 포함된 구현 파이프라인은 FHIR 번들에서 임상 플래그를 계산하고 이를 patient_360 문서에 직접 쓰기합니다. AlertEngine 은 이러한 플래그를 읽어 환자에게 적용되는 CDS 규칙을 결정합니다. 포함되는 것들은 다음과 같습니다.

• flags.has_beta_blocker: 베타 차단제 심박동 수 규칙을 활성화합니다.

• flags.has_insulin: 다요소 저혈당 규칙을 활성화합니다.

• flags.has_ckd: CKD 대사성 산증 및 호흡 규칙을 활성화합니다.

• flags.condition_codes모든 활성 상태에 대한 SNOMED 코드.

캐어 갥갑 결과도 동일한 방법을 사용합니다. 구현 파이프라인은 캐어 갥갑 결과를 계산하고 이를 patient_360 문서에 직접 추가합니다. 계산된 각 HEDIS 측정값은 연관된 status, priority, evidence 및 recommended_action와 함께 care_gaps 배열 내에 저장됩니다. 표준 FHIR과 달리 document model은 환자의 임상 기록과 함께 이 정보를 저장합니다. 이 구조의 예시는 다음과 같습니다.

{
   "care_gaps": [
      {
         "hedis_measure": "CDC-HBA",
         "measure_name": "Comprehensive Diabetes Care — HbA1c Testing",
         "status": "open",
         "days_overdue": 34,
         "priority": "high",
         "evidence": {
            "found": ["HbA1c 5.13% (2025-10-07)"],
            "missing": []
         },
         "recommended_action": "Schedule or order an HbA1c follow-up"
      }
   ]
}

이 방법은 추가적인 유연성을 제공합니다. 임상 요구 사항이 변경되면 문서를 확장할 수 있습니다. 새 CDS 규칙은 기존 필드에 영향을 주지 않고 같은 문서에 새 필드를 쓰기합니다.

소스 기록에 대한 추적 가능성

patient_360 문서는 FHIR 기록을 대체하는 것이 아니라 파생된 운영 뷰를 구성합니다. 구현 파이프라인은 FHIR 리소스에서 이 보기를 생성합니다. 임상 결정 또는 진료 결과 감사를 위해 모든 문서에 data_provenance 블록이 포함됩니다.

{
   "data_provenance": {
      "layer": "cds_operational",
      "source_fhir_collection": "synthetic_patients",
      "source_patient_id": "1b3bbaec-def8-4b55-8e87-9d04b55d6890",
      "materialization_version": "1.0",
      "last_materialized_at": "2026-05-09T21:30:04.873754+00:00",
      "fhir_resource_count": 22
   }
}

FHIR 데이터 저장소는 상호 운영성을 위한 규범적 사실 원본으로 남아 있습니다. 반면 MongoDB Atlas는 원본 데이터에 대한 직접 링크를 유지하면서 운영 보기를 유지합니다.

document model내 암호화된 필드

의료 규정에 따라 애플리케이션은 PHI를 암호화해야 합니다. 일반적인 접근 방식은 암호화된 PHI를 별도 시스템에 저장하고 필요할 때에만 검색하는 것입니다. 하지만 이 프레임워크는 두 번째 데이터 저장, 별도 키 관리 계층 및 환자 기록을 검색할 때마다 지연 시간을 증가시킵니다.

MongoDB Queryable Encryption은 동일한 문서에 PHI를 유지하여 이러한 오버헤드를 제거합니다. 환자 이름, MRN 및 생년월일과 같이 노출시 심각한 필드를 암호화 키를 가진 승인된 클라이언트 애플리케이션에서만 읽을 수 있도록 보안합니다. 문서의 나머지 부분은 운영 목적으로 계속 조회할 수 있습니다.

{
   "demographics": {
      "name": { "$binary": { "base64": "EAXZmoXjO0re...", "subType": "06" } },
      "given": { "$binary": { "base64": "EF1RChFVFEJC...", "subType": "06" } },
      "family": { "$binary": { "base64": "EK18iT8qVki8...", "subType": "06" } },
      "birth_date": { "$binary": { "base64": "EJOsqgLJPEjI...", "subType": "06" } },
      "gender": "female",
      "age": 77
   }
}

예를 들어 AlertEngine 과 QualityEngine 같은 마이크로 서비스는 플래그, 임계값 및 캐어 갭갑 필드를 읽지만 암호화된 인구 통계 필드는 읽지 않습니다.