# FHIR 대 맞춤형 의료 데이터베이스 > 자체 테이블 또는 의료 데이터를 위한 HL7 FHIR R4: 동일한 데이터를 두 가지 방식으로 저장, 장단점 비교, 각 방식이 적합한 경우, 그리고 일반적으로 자체 데이터베이스와 FHIR 레코드 간의 분할 방식. Source: https://developers.anpheros.com/ko/guides/fhir-vs-custom-database **헬스케어 제품을 시작하는 팀은 일반적으로 초기에 동일한 선택에 직면합니다. PostgreSQL 또는 다른 데이터베이스에 환자, 측정값 및 진단에 대한 자체 테이블을 설계할 것인지, 아니면 처음부터 HL7 FHIR R4 리소스로 의료 데이터를 저장할 것인지입니다.** 맞춤형 스키마는 첫날에는 더 빠르며 제품에 정확하게 맞습니다. FHIR은 초기 설계에 더 많은 고민이 필요하지만, 데이터가 시스템을 벗어나야 하거나, 감사받거나, 동의 하에 공유되거나, 본인이 아닌 다른 사람이 읽어야 할 때마다 그 가치를 발휘합니다. 이 페이지에서는 동일한 데이터를 두 가지 방식으로 저장하고 각 선택이 적합한 경우를 명시하며, 장단점을 솔직하게 제시합니다. 이것은 *어떤* FHIR 서버를 사용할 것인지에 대한 질문과는 다릅니다. 해당 내용은 [Anpheros와 다른 FHIR 서버 비교](https://developers.anpheros.com/ko/guides/fhir-server-comparison)를 참조하십시오. ## 동일한 측정값, 두 가지 방식 사용자 지정 스키마의 혈압 측정값: ```sql 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의 동일한 측정값: ```json {"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를 사용하여 의료 기록 저장하는 방법](https://developers.anpheros.com/ko/guides/store-medical-records-fhir)에서 자세히 설명합니다. ## 나란히 비교 | | 사용자 지정 스키마 | 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](https://developers.anpheros.com/ko/guides/medical-app-backend)에서 이 분할에 대해 자세히 설명하고, [How to build a healthcare API with TypeScript](https://developers.anpheros.com/ko/guides/healthcare-api-typescript)에서 이를 구축합니다. ## FHIR 직접 구축에 필요한 것 FHIR을 선택한다고 해서 FHIR 서버를 직접 작성해야 하는 것은 아닙니다. 오픈소스 서버를 직접 운영하거나, 클라우드 제공업체의 FHIR 저장소를 사용하거나, 오픈소스 의료 플랫폼을 활용하거나, Anpheros와 같은 관리형 의료 데이터베이스를 사용할 수 있습니다. 이러한 옵션들은 동의, 감사, 출처, 거주지 및 통합을 누가 처리하는지에 따라 달라지며, 이는 [Anpheros와 다른 FHIR 서버 비교](https://developers.anpheros.com/ko/guides/fhir-server-comparison)에서 자세히 설명합니다. ## 자주 묻는 질문 ### FHIR는 데이터베이스인가요? 아니요. FHIR는 건강 데이터의 구조 및 교환을 위한 표준입니다: 리소스, 코드 및 REST API. FHIR 서버 또는 관리형 FHIR 데이터베이스는 리소스를 저장하고 실제 데이터베이스 위에 API를 구현합니다. ### PostgreSQL에 FHIR 리소스를 직접 저장할 수 있나요? 예, JSON 컬럼과 자체 인덱스를 사용하여 저장할 수 있으며, 일부 오픈 소스 서버는 정확히 그렇게 합니다. 작업은 저장과 관련된 모든 것에 있습니다: 검색 매개변수, 버전 관리, 참조, 유효성 검사, 환자별 액세스 제어 및 출처. ### 사용자 지정 스키마로 시작하여 나중에 FHIR로 전환할 수 있나요? 예, 가능하며 많은 팀이 그렇게 합니다. 하지만 마이그레이션은 매핑 프로젝트입니다: 모든 테이블은 기록한 적이 없는 코드, 단위 및 작성자가 필요합니다. 처음부터 의료 데이터를 FHIR로 저장하는 것이 나중에 변환하는 것보다 비용이 적게 듭니다. ### GDPR 준수를 위해 FHIR가 필요한가요? 아니요. GDPR은 특정 형식을 요구하지 않습니다. FHIR는 여러 의무를 더 쉽게 충족할 수 있도록 합니다: 이식성 (레코드가 표준 형식으로 내보내짐), 목적별 액세스 제어, 그리고 누가 어떤 데이터를 처리했는지 보여주는 것. ## 관련 자료 - [FHIR 데이터베이스 스키마](https://developers.anpheros.com/ko/guides/fhir-database-schema): FHIR 리소스가 저장되고 인덱싱되는 방식 - [FHIR R4를 사용하여 의료 기록 저장 방법](https://developers.anpheros.com/ko/guides/store-medical-records-fhir) - [FHIR 플랫폼](https://developers.anpheros.com/ko/guides/fhir) - [Anpheros와 다른 FHIR 서버 비교](https://developers.anpheros.com/ko/guides/fhir-server-comparison) - [의료 앱 백엔드 및 데이터베이스](https://developers.anpheros.com/ko/guides/medical-app-backend) - [Healthcare API](https://developers.anpheros.com/ko/guides/healthcare-api)