하이브리드 FHIR 운영 데이터 계층

솔루션 개요

이 프로젝트에서는 의료 분야를 위한 FHIR 하이브리드 ODL 패턴을 개발합니다. 주요 목표는 고성능의 단일 운영 스토리지를 만들어 고객 웹 서비스를 지원하는 것입니다. 또한 이 설계는 범위 내 리소스에 대해 FHIR 호환 엔드포인트를 노출하므로 향후 기능을 빌드할 떼 새로운 사용자 지정 서비스 대신 FHIR REST API를 사용할 수 있습니다.

ODL은 Patient 또는 Encounter와 같은 리소스를 구조화된 3블록 형식으로 저장하는 유연하고 확장 가능한 데이터베이스인 MongoDB Atlas를 사용하는 것입니다. 여기에는 다음이 포함됩니다.

• 매핑이 존재할 때의 표준 FHIR 표현

• 추가 애플리케이션별 필드

• 사전 인덱스 검색을 통해 쿼리 성능에 최적화된 필드

매핑은 FHIR 우선으로 정의되므로 FHIR과 정렬된 필드는 표준 구조를 사용하여 저장되고, 나머지 속성은 별도의 애플리케이션 블록에 보관됩니다. 이 하이브리드 구조는 솔루션이 완전한 FHIR 서버로 작동하도록 강제하지 않고도 상호 운용성을 유지합니다.

백엔드는 FastAPI를 사용하며 다음 두 가지 API 제품군을 제공합니다.

• 애플리케이션 API: ODL을 공유 백엔드로 사용하여 환자 검색, 사례 검색 또는 로컬 식별자 서비스와 같은 고객의 운영 엔드포인트를 구현합니다.

• FHIR API: Patient, Encounter 등의 정의된 리소스 부분집합에 대해 FHIR 호환 검색을 제공하며, 동일한 엔벨로프 모델과 인덱스를 재사용합니다. 이 서버는 실용적인 FHIR 파사드로 설계되었으며 완전한 프로필 기반 FHIR 서버가 아닙니다.

프론트엔드는 Next.js를 사용하고 대화형 API 데모가 포함되어 있어 팀이 애플리케이션 엔드포인트와 FHIR 스타일 쿼리를 함께 시도해볼 수 있습니다.

ODL은 데모 및 개발을 위해 합성 임상 데이터 세트를 생성하므로 실제 환자 데이터를 노출하지 않고도 사실적인 테스트를 수행할 수 있습니다.

참조 아키텍처

이 아키텍처는 동일한 데이터 집합에 대한 사용자 지정 운영 액세스 패턴과 FHIR 호환 액세스를 지원하는 참조 데이터 모델 접근 방식인 FHIR 하이브리드 ODL에 중점을 둡니다. 이 접근 방식은 데이터를 복제하는 대신 운영 쿼리에 필요한 중요한 정보를 인덱싱하고 전체 FHIR 리소스를 유지 관리합니다.

이 사용 사례는 여러 EHR 플랫폼을 운영하는 대형 의료 기관이 겪은 실제 고객 과제에서 비롯되었습니다. 각 시스템이 환자 액세스 서비스를 독립적으로 제공했기 때문에 데이터 액세스가 파편화되고, 로직이 중복되며, 시맨틱 상호 운용성이 부족했습니다.

이를 단순화하기 위해 기관에서는 기존 애플리케이션을 중단하지 않으면서 임상 데이터 액세스를 중앙 집중화하고 공유 MDM 서비스를 제공하는 ODL을 도입했습니다.

이러한 상황은 데이터 구조와 의미를 무에서 재정의하는 대신 FHIR을 공통 언어로 채택함으로써 업계 권장 사항으로 전환하는 계기를 마련했습니다. 이 조직은 ODL 데이터 모델을 FHIR 우선 방식으로 설계함으로써, 환자와 진료 기록과 같은 핵심 개념을 다시 정의하는 비효율을 피할 수 있었습니다. 또한 표준 리소스 정의와도 일치하여 해당 분야의 다른 기관에서도 참고할 수 있는 잠재적인 모델이 되었습니다.

참조 아키텍처는 의료 서비스 회사가 MongoDB Atlas를 사용하여 다양한 데이터 소스를 통합하고, 사용자 정의 프로세스를 지원하고, 고성능 API를 제공할 수 있는 방법을 보여줍니다. 인터페이스는 탭으로 나뉘며, 각 탭은 아키텍처의 특정 역량을 표시합니다.

그림 1. FHIR 하이브리드 ODL 참조 아키텍처

처음에는 매핑 섹션이 레거시 의료 데이터 필드가 FHIR 중심 스키마를 중심으로 설계된 ODL 데이터 모델에 매핑되는 방법을 보여줍니다. 각 문서에는 다음이 저장됩니다.

• FHIR 매핑이 존재할 때 표준 FHIR 리소스

• 현재 워크플로에 필요한 애플리케이션별 필드

• API에서 사용하는 검색 최적화 필드

사용자는 Patient, Encounter와 같은 항목의 전체 필드 매핑 세트를 대화형 테이블에서 찾아볼 수 있습니다. 이를 통해 어떤 필드가 FHIR 사양에서 왔으며 어떤 필드가 애플리케이션 또는 검색 필드로 모델링되었는지 이해하는 데 도움이 됩니다. 이 매핑 전략을 사용하면 데이터 계보를 더 쉽게 추적하고 표준과의 일치 여부를 평가할 수 있습니다.

그림 2. 하이브리드 FHIR ODL 데모의 매핑 탭

플랫폼에는 저장 및 검색 테스트를 위한 합성 임상 데이터를 생성하는 내장 생성기가 포함되어 있어 팀이 기능을 테스트할 수 있습니다. 사용자는 환자 수, 환자당 진료 횟수, 의료진 및 진료팀 등의 합성 콘텐츠를 사용자 지정할 수 있습니다.

그림 3: 합성 임상 데이터 생성기

데이터가 채워진 후, 데이터 뷰어 섹션에서는 MongoDB에 저장된 FHIR 리소스를 탐색할 수 있습니다. 표준 FHIR 콘텐츠와 추가 ODL 필드를 한 곳에 표시하여 표준 데이터와 운영 데이터가 함께 사용되는 방식을 명확히 보여줍니다.

고객 API 섹션은 레거시 의료 시스템을 플랫폼과 통합합니다. API 테스터를 통해 고객별 MDM 및 운영 엔드포인트를 호출할 수 있습니다. 엔드포인트를 선택하고 필요한 매개변수를 입력하면, 쿼리를 실행해 사용자 지정 시스템에서 예상하는 대로 형식이 지정된 응답을 볼 수 있습니다.

마지막으로, FHIR API 테스터 섹션에서는 사용자가 기본 데이터 세트에 대해 FHIR 표준을 검색할 수 있습니다. 결과에는 MongoDB 쿼리 파이프라인과 FHIR 응답이 표시됩니다. 이 보기에서는 플랫폼이 FHIR 표준을 준수하는 출력을 유지하고, 성능 인사이트를 제공하며, 디버깅 세부 정보를 제공하는 방법을 볼 수 있습니다.

데이터 모델 접근 방식

아키텍처는 MongoDB에 저장된 FHIR 중심의 ODL 스키마를 기반으로 빌드되었습니다. 환자 및 진료 데이터를 여러 테이블에 분산시키는 대신 각 기록이 세 섹션이 있는 단일 문서로 유지됩니다. 각 섹션은 ODL 내에서 특정 목적을 제공합니다.

• resource 정식 FHIR 내용: Patient 또는 Encounter와 같은 유효한 R4 FHIR 객체를 포함합니다. 이 블록은 추가 변환 없이 FHIR 스타일 엔드포인트에서 직접 반환할 수 있습니다.

• app 애플리케이션 메타데이터의 경우: 워크플로에 필요하지만 기본 FHIR 리소스의 일부인 필드를 보유합니다. 여기에는 내부 코드, 분류 플래그 또는 기타 고객 속성과 같은 필드가 포함됩니다.

• search 비정규화된 쿼리 표면의 경우: 이름, 주요 날짜, 조직 또는 위치 참조와 같은 식별자를 포함하여 쿼리에서 가장 자주 사용되는 속성을 평탄화합니다. 또한 관계 키를 API 계층에서 쉽게 인덱스할 수 있고 사용 가능한 필드로 변환합니다.

아래에서 Encounter 리소스에 대한 주석이 달린 JSON 예시를 찾을 수 있습니다.

{
   "_id": "ObjectId",
   "tenant": "tenant-1",
   "resourceType": "Encounter",
   // 1 Canonical FHIR block
   "resource": {
      "resourceType": "Encounter",
      "id": "036fcfcd-797c-4ae2-a30f-49226357deb2",
      ...,
      "status": "onhold",
      "class": {
         "code": "EMER"
      },
      "serviceType": {
         ...
      },
      "period": {
         "start": "2025-10-31T17:43:00",
         "end": "2025-11-02T17:43:00"
      },
      "serviceProvider": {},
      "hospitalization": {},
      "participant": [],
      "location": [],
      "type": [
         { ... }
      ]
   },
   // 2 Application block
   "app": {
      "caseNum": "QH-1761928980-83",
      "doctorCode": "DR100",
      "specialistCode": "DR100",
      ...,
      "sourceIndicator": "SELF",
      "patientGroup": "G2"
   },
   // 3 Search block
   "search": {
      "start": "2025-10-31T17:43:00",
      "end": "2025-11-02T17:43:00",
      "local_id": "A108548(0)",
      ...,
      "caseNum": "QH-1761928980-83",
      "statusCode": "onhold",
      "caseType": "E"
   }
}

솔루션 빌드

자세한 설정 지침은 이 GitHub 리포지토리의 README에 설명된 단계를 따르세요. 이 리포지토리는 이 데모의 백엔드와 프론트엔드를 호스팅합니다.

사용자 환경에서 이 데모를 재현하려면 다음 단계를 따르세요.

git clone https://github.com/mongodb-industry-solutions/hybrid-fhir-odl.git
cd hybrid-odl

MONGODB_URI=mongodb+srv://<user>:<password>@<cluster-url>/?retryWrites=true&w=majority
MONGODB_DB=fhir_demo
MONGODB_COLLECTION=fhir
MONGODB_TENANT=tenant-1

NEXT_PUBLIC_ENABLE_FHIR = true
BACKEND_URL=http://localhost:3100

make install

make backend

make frontend

주요 학습 사항

• 레거시 의료 시스템 현대화: 이 솔루션은 병원이 운영 워크플로를 중단하지 않고도 임상 데이터 인프라를 업데이트하는 방법을 보여줍니다. 이 접근 방식은 기관이 기존의 완전 맞춤형 서비스를 계속 유지하거나 FHIR로 전면 전환해야 하는 부담 없이 시스템을 점진적으로 통합할 수 있도록 지원합니다. 데이터는 FHIR 리소스로 계속 사용할 수 있으며, 사용자 지정 애플리케이션 엔드포인트와 기존 쿼리 패턴은 애플리케이션 API 계층을 통해 계속 작동합니다. 이 솔루션을 사용하는 병원은 임상 팀과 제휴 시스템을 자체 속도로 이동하여 인프라를 점진적으로 현대화할 수 있습니다.

• 임상 데이터 성능 최적화: 이 접근 방식을 사용하면 표준 컴플라이언스를 위해 리소스 블록에서 FHIR 데이터를 변경하지 않고 유지하면서 애플리케이션 정보를 사용 빈도가 높은 속성, 인덱스에 저장하여 검색 성능을 높일 수 있습니다. 이 시스템은 실시간 임상 대시보드, 운영 분석, 등록, 분류 및 병상 관리 중 빠른 조회에 적합합니다.

• 상호 운용성 및 개발자 생산성 가속화: 이중 API 아키텍처, 내장된 합성 데이터 생성 및 대화형 API 테스트 도구 덕분에 기존 병원 프로세스를 중단하지 않고도 FHIR 준수 솔루션을 신속하게 프로토타이핑, 검증 및 배포할 수 있습니다.

작성자

• Patricia Renart Carnicero, MongoDB

• Francesc Mateu Amengual, MongoDB

자세히 알아보기

• MongoDB와 Microsoft를 활용한 AI 기반 의료

• AI 기반 소매: 개인화 및 정확성

• 기술 Docs 용 컨텍스트 인식 RAG