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

FHIR डेटाबेस स्कीमा

FHIR संसाधनों को कैसे स्टोर करें: सामान्यीकृत टेबल बनाम JSON खोज इंडेक्स के साथ बनाम ग्राफ़, PostgreSQL स्कीमा एंफ़ेरोस चलाता है (संसाधन, इतिहास, टाइप किए गए इंडेक्स, प्रोजेक्शन) और नियम जो मायने रखते हैं।

एक FHIR डेटाबेस HL7 FHIR संसाधनों को स्टोर करता है ताकि उन्हें FHIR API के माध्यम से पढ़ा, खोजा और संस्करणित किया जा सके; सबसे आम स्कीमा प्रत्येक संसाधन को JSON के रूप में रखता है और सर्च पैरामीटर के लिए अलग इंडेक्स टेबल भरता है, बजाय इसके कि हर तत्व को सामान्यीकृत रिलेशनल टेबल में फैलाया जाए। यह पृष्ठ तीन सामान्य डिज़ाइनों, PostgreSQL में Anpheros द्वारा चलाए जाने वाले स्कीमा और जब आपको स्वयं एक नहीं बनाना चाहिए, इसकी व्याख्या करता है।

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`	संदर्भ खोज मान	लक्ष्य प्रकार और आईडी — `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 को वैसे ही लौटाता है जैसे वह लिखा गया था।

महत्वपूर्ण डिज़ाइन नियम

केवल घोषित खोज पैरामीटर (search parameters) को इंडेक्स करें, और अज्ञात पैरामीटर को चुपचाप अनदेखा करने के बजाय 400 के साथ अस्वीकार करें।
इतिहास (history) के बिना कभी भी इन-प्लेस अपडेट न करें: सुधारों को वही रखना चाहिए जो पहले ज्ञात था।
सॉफ्ट डिलीट (Soft delete): एक डिलीट किया गया संसाधन रीड (reads) और सर्च (searches) से गायब हो जाता है, लेकिन ऑडिट (audit) के लिए उसके संस्करण (versions) बने रहते हैं।
पेशेंट कम्पार्टमेंट कॉलम (Patient compartment column): हर संसाधन पर patient_id को स्टोर करने से $everything, सहमति फिल्टर (consent filters) और प्रति-पेशेंट अलगाव (per-patient isolation) सस्ता हो जाता है।
स्टोर करने से पहले मान्य करें (Validate before storing): स्टोर में अमान्य JSON बाद में हर रीडर को तोड़ देता है।

अक्सर पूछे जाने वाले प्रश्न

FHIR के लिए सबसे अच्छा डेटाबेस कौन सा है?

अधिकांश प्रोडक्शन FHIR सर्वर रिलेशनल डेटाबेस जैसे PostgreSQL का उपयोग करते हैं, जिसमें रिसोर्स को JSON (JSONB) के रूप में स्टोर किया जाता है और सर्च पैरामीटर को अलग-अलग टेबल में इंडेक्स किया जाता है। यह लचीले स्टोरेज को तेज, मानक सर्च के साथ जोड़ता है।

क्या मुझे FHIR रिसोर्स को रिलेशनल टेबल में नॉर्मलाइज़ करना चाहिए?

आमतौर पर प्राइमरी स्टोर के लिए नहीं। नॉर्मलाइज़्ड टेबल रिपोर्टिंग के लिए उपयुक्त हैं; उन्हें स्टोर्ड रिसोर्स से बने प्रोजेक्शन के रूप में रखें, जैसा कि Anpheros अपने सरल REST API के लिए करता है।

HAPI FHIR रिसोर्स कैसे स्टोर करता है?

HAPI FHIR का JPA सर्वर प्रत्येक रिसोर्स वर्जन को सीरियलाइज़्ड JSON के रूप में स्टोर करता है और सर्च पैरामीटर को अलग इंडेक्स टेबल में रखता है। Anpheros डिज़ाइन भी इसी सिद्धांत का पालन करता है।

क्या मुझे खुद FHIR डेटाबेस बनाना होगा?

केवल तभी जब आपको प्रोफाइल और रिसोर्स प्रकारों पर पूर्ण नियंत्रण की आवश्यकता हो। अन्यथा, एक प्रबंधित FHIR प्लेटफ़ॉर्म आपको स्कीमा चलाए बिना स्टोरेज, सर्च, हिस्ट्री, कंसेंट और ऑडिट प्रदान करता है।