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()
);

सरल, क्वेरी करने में तेज़, वही जो ऐप को चाहिए। फिर ऐसे सवाल आते हैं जिनका जवाब टेबल नहीं देता:

यह मान किस डिवाइस या व्यक्ति ने उत्पन्न किया? क्या इसे मरीज़ ने टाइप किया था, कफ से मापा गया था, या नर्स ने दर्ज किया था?
किसी के ठीक करने से पहले मान क्या था, और किसने ठीक किया?
क्लिनिक सिस्टम, लैब या बीमाकर्ता इसे कैसे पढ़ते हैं? उनके सिस्टम में 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 आयात, इंटरनेशनल पेशेंट समरी
प्रति एप्लिकेशन रोगी की सहमति	आप इसे डिज़ाइन करते हैं	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

आपका डेटाबेस छोटा और उत्पाद के आकार का रहता है। मेडिकल रिकॉर्ड मानक, संस्करणित और साझा करने योग्य है, और आपको इसे बनाने की आवश्यकता नहीं है। मेडिकल ऐप बैकएंड और डेटाबेस इस विभाजन का विस्तार से वर्णन करता है, और TypeScript के साथ हेल्थकेयर API कैसे बनाएं इसे बनाता है।

FHIR स्वयं बनाने के लिए क्या आवश्यक है

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

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

क्या FHIR एक डेटाबेस है?

नहीं। FHIR स्वास्थ्य डेटा की संरचना और आदान-प्रदान के लिए एक मानक है: संसाधन, कोड और एक REST API। एक FHIR सर्वर या प्रबंधित FHIR डेटाबेस संसाधनों को संग्रहीत करता है और एक वास्तविक डेटाबेस के ऊपर API को लागू करता है।

क्या मैं स्वयं PostgreSQL में FHIR संसाधन संग्रहीत कर सकता हूँ?

हाँ, JSON कॉलम के रूप में अपने स्वयं के इंडेक्स के साथ, और कुछ ओपन-सोर्स सर्वर ठीक यही करते हैं। काम भंडारण के आसपास की हर चीज़ में है: खोज पैरामीटर, संस्करण, संदर्भ, सत्यापन, प्रति रोगी एक्सेस नियंत्रण और उत्पत्ति।

क्या मैं एक कस्टम स्कीमा से शुरू कर सकता हूँ और बाद में FHIR पर जा सकता हूँ?

आप कर सकते हैं, और कई टीमें करती हैं, लेकिन माइग्रेशन एक मैपिंग प्रोजेक्ट है: हर टेबल को कोड, यूनिट और लेखकों की आवश्यकता होती है जो उसने कभी रिकॉर्ड नहीं किए। पहले फ़ीचर से ही FHIR के रूप में मेडिकल डेटा संग्रहीत करने की लागत बाद में इसे परिवर्तित करने की तुलना में कम है।

क्या मुझे GDPR का अनुपालन करने के लिए FHIR की आवश्यकता है?

नहीं। GDPR के लिए किसी विशेष प्रारूप की आवश्यकता नहीं है। FHIR कई दायित्वों को पूरा करना आसान बनाता है: पोर्टेबिलिटी (रिकॉर्ड एक मानक प्रारूप में निर्यात होता है), उद्देश्य के अनुसार एक्सेस नियंत्रण, और यह दिखाना कि किसने किस डेटा को संसाधित किया।