Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card

FHIR 데이터베이스 스키마

FHIR 리소스를 저장하는 방법: 정규화된 테이블 대 검색 인덱스가 있는 JSON 대 그래프, Anpheros가 실행하는 PostgreSQL 스키마(리소스, 기록, 유형별 인덱스, 프로젝션) 및 중요한 규칙.

FHIR 데이터베이스는 HL7 FHIR 리소스를 저장하여 FHIR API를 통해 읽고, 검색하고, 버저닝할 수 있도록 합니다. 가장 일반적인 스키마는 각 리소스를 JSON으로 유지하고 검색 매개변수에 대한 별도의 인덱스 테이블을 채우는 방식이며, 모든 요소를 정규화된 관계형 테이블에 분산시키는 방식과는 다릅니다. 이 페이지에서는 세 가지 일반적인 디자인, Anpheros가 PostgreSQL에서 실행하는 스키마, 그리고 직접 구축하지 말아야 할 경우에 대해 설명합니다.

FHIR 저장 방법 세 가지

Three ways to store FHIR data

	Normalised tables	JSON + search indexes	Graph database
Stores any valid resource unchanged	—	✓	✓
Standard FHIR search on any parameter	◐	✓	◐
New fields need a schema migration	✓	—	—
Easy SQL reporting	✓	◐	—
Used by mainstream FHIR servers	◐	✓	—

◐ = possible with extra work. HAPI FHIR and Anpheros both keep the resource as JSON and index search parameters separately.

FHIR 리소스는 깊이가 있고, 선택적이며, 확장 가능합니다. Observation 하나만 해도 수십 개의 요소, 선택 유형(value[x]), 반복되는 코딩 및 확장을 가지고 있습니다. 이를 관계형 열로 정규화하면 프로필이 필드를 추가할 때마다 마이그레이션이 필요합니다. 리소스를 JSON으로 유지하면 유효한 모든 것이 변경되지 않고 저장되며, 인덱스 테이블을 통해 검색 가능하게 됩니다.

Anpheros 스키마

How a FHIR database is laid out (the Anpheros design)

APIFHIR R4 REST and the simpler /v1 REST API
Current resourcesOne row per resource: type, id, patient, version, the full FHIR JSON (JSONB)
Search indexesTyped tables filled on every write: token, string, date, reference, quantity
HistoryEvery version of every resource, never overwritten
ProjectionsFlat tables for the common REST views: observations, conditions, medications
PostgreSQLOne database per environment; sandbox and production are separate

테이블	행당 항목	키 컬럼
`fhir_resources`	리소스의 현재 버전	`resource_type`, `id`, `patient_id`, `version`, `json` (전체 리소스), `last_updated`, `deleted`, 프로비넌스 컬럼
`fhir_history`	기록된 모든 버전	`resource_type`, `id`, `version`, `json`, `last_updated`
`idx_token`	코딩 또는 식별자 검색 값	system, code — `code`, `category`, `identifier`, `status`의 경우
`idx_string`	텍스트 검색 값	정규화된 텍스트 — 이름 및 자유 텍스트의 경우
`idx_date`	날짜 검색 값	범위의 시작 및 끝 — `date`, `onset-date`, `birthdate`의 경우
`idx_reference`	참조 검색 값	대상 유형 및 ID — `patient`, `subject`, `encounter`의 경우
`idx_quantity`	수량 검색 값	값, system, unit — `value-quantity`의 경우
`proj_observations`, `proj_conditions`, `proj_medications`	리소스, 플랫화됨	간단한 REST API 필터링에 사용되는 컬럼

쓰기 작업 시마다 플랫폼은 리소스를 검증하고, 새 버전을 fhir_resources 및 fhir_history에 기록하며, 인덱스 행과 프로젝션을 교체하고, 프로비넌스를 기록합니다. Observation?patient=…&code=http://loinc.org|4548-4&date=ge2026-01-01과 같은 검색은 idx_reference, idx_token 및 idx_date에 대한 조인이 됩니다. 결과는 기록된 그대로의 JSON을 반환합니다.

중요한 디자인 규칙

선언된 검색 매개변수만 인덱싱하고, 알 수 없는 매개변수는 무시하지 않고 400로 거부합니다.
기록 없이 인플레이스 업데이트 금지: 수정 시 이전 정보는 유지되어야 합니다.
소프트 삭제: 삭제된 리소스는 읽기 및 검색에서 사라지지만, 감사 목적으로 해당 버전은 유지됩니다.
환자 컴파트먼트 열: 모든 리소스에 patient_id를 저장하면 $everything, 동의 필터 및 환자별 격리가 용이해집니다.
저장 전 유효성 검사: 저장소에 유효하지 않은 JSON은 나중에 모든 리더에 문제를 일으킵니다.

자주 묻는 질문

FHIR에 가장 적합한 데이터베이스는 무엇인가요?

대부분의 프로덕션 FHIR 서버는 PostgreSQL과 같은 관계형 데이터베이스를 사용하며, 리소스는 JSON(JSONB)으로 저장하고 검색 매개변수는 별도의 테이블에 인덱싱합니다. 이는 유연한 저장과 빠르고 표준적인 검색을 결합합니다.

FHIR 리소스를 관계형 테이블로 정규화해야 하나요?

일반적으로 기본 저장소에는 그렇지 않습니다. 정규화된 테이블은 보고에 적합합니다. Anpheros가 더 간단한 REST API를 위해 수행하는 것처럼 저장된 리소스에서 빌드된 프로젝션으로 유지하세요.

HAPI FHIR는 리소스를 어떻게 저장하나요?

HAPI FHIR의 JPA 서버는 각 리소스 버전을 직렬화된 JSON으로 저장하고 검색 매개변수를 별도의 인덱스 테이블에 유지합니다. Anpheros 디자인은 동일한 원칙을 따릅니다.

FHIR 데이터베이스를 직접 구축해야 하나요?

프로파일 및 리소스 유형에 대한 완전한 제어가 필요한 경우에만 해당됩니다. 그렇지 않으면 관리형 FHIR 플랫폼을 사용하면 스키마를 실행하지 않고도 저장, 검색, 기록, 동의 및 감사를 제공받을 수 있습니다.