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

솔루션 개요

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

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

• 매핑이 존재할 때 표준 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 플랫폼을 운영하는 대규모 의료 기관과 관련된 실제 고객 과제 에서 비롯된 것입니다. 각 시스템이 환자 액세스 서비스를 독립적으로 제공했기 때문에 데이터 액세스 파편화되고, 로직이 중복되고, 시맨틱 상호 운용성 부재가 발생했습니다.

이 기관은 이를 간소화하기 위해 ODL을 도입하여 기존 애플리케이션을 중단하지 않고도 의료 데이터 액세스 중앙 집중화하고 공유 MDM 서비스를 제공했습니다.

이러한 상황은 데이터 구조와 의미 체계를 무에서 재정의하는 대신 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 콘텐츠의 경우: 4 Patient 또는 와 같은 유효한 R FHIR 객체 Encounter 포함합니다. 이 차단 추가 변환 없이 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"
   }
}

솔루션 빌드

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

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

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 호환 솔루션의 프로토타입을 신속하게 제작하고, 검증하고, 배포 수 있습니다.

작성자

• 패트리샤 르나트 카니세로, MongoDB

• Francesc Mateu Amengual, MongoDB

자세히 알아보기

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

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

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