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

FHIR 대 사용자 정의 의료 데이터베이스

의료 데이터를 위한 자체 테이블 또는 HL7 FHIR R4: 동일한 읽기 저장 방식 비교, 장단점 비교, 각 솔루션이 적합한 경우, 데이터베이스와 FHIR 레코드 간의 일반적인 분할.

헬스케어 제품을 시작하는 팀은 일반적으로 초기에 동일한 선택에 직면합니다. PostgreSQL 또는 다른 데이터베이스에 환자, 측정값 및 진단에 대한 자체 테이블을 설계할 것인지, 아니면 처음부터 HL7 FHIR R4 리소스로 의료 데이터를 저장할 것인지입니다. 맞춤형 스키마는 첫날에는 더 빠르며 제품에 정확하게 맞습니다. FHIR은 초기 설계에 더 많은 고민이 필요하지만, 데이터가 시스템을 벗어나야 하거나, 감사받거나, 동의 하에 공유되거나, 본인이 아닌 다른 사람이 읽어야 할 때마다 그 가치를 발휘합니다. 이 페이지에서는 동일한 데이터를 두 가지 방식으로 저장하고 각 선택이 적합한 경우를 명시하며, 장단점을 솔직하게 제시합니다.

이것은 어떤 FHIR 서버를 사용할 것인지에 대한 질문과는 다릅니다. 해당 내용은 Anpheros와 다른 FHIR 서버 비교를 참조하십시오.

동일한 측정값, 두 가지 방식

사용자 지정 스키마의 혈압 측정값:

CREATE TABLE bp_readings (
  id          uuid PRIMARY KEY,
  user_id     uuid REFERENCES users(id),
  systolic    int,
  diastolic   int,
  measured_at timestamptz,
  created_at  timestamptz DEFAULT now()
);

간단하고 쿼리가 빠르며 앱에 필요한 정확한 정보입니다. 하지만 이 테이블로는 답할 수 없는 질문들이 있습니다.

해당 값을 생성한 기기 또는 사람은 누구인가요? 환자가 직접 입력한 것인가요, 커프(cuff)로 측정된 것인가요, 아니면 간호사가 입력한 것인가요?
누군가 수정하기 전의 값은 무엇이며, 누가 수정했나요?
클리닉 시스템, 실험실 또는 보험사가 이를 어떻게 읽나요? 해당 시스템에서 systolic는 무엇을 의미하나요?
환자가 이를 의사의 앱과 공유하고 다음 달에는 공유를 중단하려면 어떻게 해야 하나요?
심박수, 체중, HbA1c 및 기타 200가지 측정값을 추가할 때, 이는 200개의 테이블인가요, 아니면 직접 설계한 하나의 일반 테이블인가요?

FHIR R4의 동일한 측정값:

{"resourceType": "Observation", "status": "final",
 "category": [{"coding": [{"system": "http://terminology.hl7.org/CodeSystem/observation-category", "code": "vital-signs"}]}],
 "code": {"coding": [{"system": "http://loinc.org", "code": "85354-9", "display": "Blood pressure panel"}]},
 "subject": {"reference": "Patient/d09e3942-…"}, "effectiveDateTime": "2026-10-10T08:30:00Z",
 "component": [
   {"code": {"coding": [{"system": "http://loinc.org", "code": "8480-6"}]}, "valueQuantity": {"value": 138, "unit": "mmHg", "system": "http://unitsofmeasure.org", "code": "mm[Hg]"}},
   {"code": {"coding": [{"system": "http://loinc.org", "code": "8462-4"}]}, "valueQuantity": {"value": 88, "unit": "mmHg", "system": "http://unitsofmeasure.org", "code": "mm[Hg]"}}],
 "meta": {"versionId": "1"}}

더 장황하지만, 각 부분은 모든 FHIR 시스템이 공유하는 의미를 가지고 있습니다. LOINC는 무엇을 측정했는지, UCUM은 단위를 나타내며, meta.versionId는 기록을 시작하고, 동일한 Observation 구조는 나머지 200가지 측정값을 담습니다. Anpheros를 사용하면 Provenance 리소스는 누가 작성했는지도 기록합니다. FHIR R4를 사용하여 의료 기록 저장하는 방법에서 자세히 설명합니다.

나란히 비교

	사용자 지정 스키마	FHIR R4
첫 번째 기능까지의 시간	시간	리소스를 학습하는 데 하루 또는 이틀
제품에 대한 적합성	정확함	일반적; 제품의 뷰가 위에 놓임
새로운 종류의 데이터 추가	종류별 마이그레이션	일반적으로 기존 리소스에 새 코드 추가
시스템 외부에서의 의미	매핑 없이는 없음	공유 코드 (LOINC, ICD-10, ATC, UCUM)
기록 및 수정	직접 설계	버전 및 `_history` 설계에 포함
누가 무엇을 작성했는지	직접 설계	`Provenance` (Anpheros에서 자동)
진료소, 실험실, 기타 앱과의 교환	매번 사용자 지정 통합	FHIR R4 API, HL7 v2 가져오기, International Patient Summary
애플리케이션별 환자 동의	직접 설계	SMART on FHIR 범위 및 OAuth
분석을 위한 쿼리	일반 SQL	FHIR 검색 또는 창고로 내보내기
규정 (GDPR 제9조, EHDS)	모든 부분을 문서화	규정에서 참조하는 표준 형식

사용자 지정 스키마가 적합한 경우

데이터가 실제 의료 데이터가 아니거나 한 사람에 대한 것이 아닌 경우. 훈련 계획, 콘텐츠, 제품 카탈로그 등은 자체 테이블을 사용하십시오.
단기 프로토타입으로 제품을 원하는지 테스트하고, 합성 데이터를 사용하며, 이후 마이그레이션 계획이 있는 경우.
표준 모델로 잘 표현되지 않는 데이터 (예: 새로운 연구 측정값). FHIR은 여전히 이를 전달할 수 있습니다 (자체 코드 시스템을 사용한 Observation 또는 Basic). 하지만 사용자 지정 테이블이 더 명확할 수 있습니다.
집중적인 분석. FHIR을 시스템 기록으로 사용하더라도 대부분의 팀은 보고를 위해 데이터를 자체 형식으로 웨어하우스로 복사합니다.

FHIR이 적합한 경우

데이터가 개인의 건강 기록인 경우: 측정값, 진단, 약물, 알레르기, 검사 결과, 문서.
데이터가 시스템을 벗어나야 하는 경우: 환자, 의사, 클리닉, 검사실, 보험사, AI 모델 또는 환자가 이동할 경우 경쟁사.
누가 무엇을 작성했으며 무엇이 변경되었는지 보여주어야 하는 경우: 감사, 임상 안전, 분쟁.
환자가 애플리케이션별로 액세스 권한을 부여하고 취소하는 경우.
유럽 연합에서 판매하는 경우, 유럽 건강 데이터 공간(European Health Data Space)은 기록이 표준 형식으로 교환될 것으로 예상합니다.

일반적인 중간 경로

대부분의 제품은 데이터 종류별로 분할하여 두 가지 모두를 사용하게 됩니다.

your database                         FHIR record (Anpheros)
─────────────                         ──────────────────────
users, sessions, settings             Patient
subscriptions, billing                Observation, Condition, MedicationStatement
product content, feature flags        AllergyIntolerance, Immunization, DocumentReference
user id → patient id (one column)     Provenance, Consent, history
caches and analytics copies  ◄─────── webhooks

데이터베이스는 작고 제품에 적합한 형태로 유지됩니다. 의료 기록은 표준화되고 버전 관리되며 공유 가능하며, 직접 구축할 필요가 없습니다. Medical app backend and database에서 이 분할에 대해 자세히 설명하고, How to build a healthcare API with TypeScript에서 이를 구축합니다.

FHIR 직접 구축에 필요한 것

FHIR을 선택한다고 해서 FHIR 서버를 직접 작성해야 하는 것은 아닙니다. 오픈소스 서버를 직접 운영하거나, 클라우드 제공업체의 FHIR 저장소를 사용하거나, 오픈소스 의료 플랫폼을 활용하거나, Anpheros와 같은 관리형 의료 데이터베이스를 사용할 수 있습니다. 이러한 옵션들은 동의, 감사, 출처, 거주지 및 통합을 누가 처리하는지에 따라 달라지며, 이는 Anpheros와 다른 FHIR 서버 비교에서 자세히 설명합니다.

자주 묻는 질문

FHIR는 데이터베이스인가요?

아니요. FHIR는 건강 데이터의 구조 및 교환을 위한 표준입니다: 리소스, 코드 및 REST API. FHIR 서버 또는 관리형 FHIR 데이터베이스는 리소스를 저장하고 실제 데이터베이스 위에 API를 구현합니다.

PostgreSQL에 FHIR 리소스를 직접 저장할 수 있나요?

예, JSON 컬럼과 자체 인덱스를 사용하여 저장할 수 있으며, 일부 오픈 소스 서버는 정확히 그렇게 합니다. 작업은 저장과 관련된 모든 것에 있습니다: 검색 매개변수, 버전 관리, 참조, 유효성 검사, 환자별 액세스 제어 및 출처.

사용자 지정 스키마로 시작하여 나중에 FHIR로 전환할 수 있나요?

예, 가능하며 많은 팀이 그렇게 합니다. 하지만 마이그레이션은 매핑 프로젝트입니다: 모든 테이블은 기록한 적이 없는 코드, 단위 및 작성자가 필요합니다. 처음부터 의료 데이터를 FHIR로 저장하는 것이 나중에 변환하는 것보다 비용이 적게 듭니다.

GDPR 준수를 위해 FHIR가 필요한가요?

아니요. GDPR은 특정 형식을 요구하지 않습니다. FHIR는 여러 의무를 더 쉽게 충족할 수 있도록 합니다: 이식성 (레코드가 표준 형식으로 내보내짐), 목적별 액세스 제어, 그리고 누가 어떤 데이터를 처리했는지 보여주는 것.