संक्षिप्त उत्तर: स्वास्थ्य डेटा मानकों की चार परतों से होकर गुजरता है। एक्सचेंज मानक सिस्टम के बीच डेटा ले जाते हैं: HL7 v2 संदेश, CDA दस्तावेज़, FHIR संसाधन और छवियों के लिए DICOM। मॉडलिंग और स्टोरेज मानक बताते हैं कि सिस्टम के अंदर एक रिकॉर्ड कैसे संरचित होता है: नैदानिक रिकॉर्ड के लिए openEHR, अनुसंधान डेटाबेस के लिए OMOP। शब्दावली हर अवधारणा को एक कोड देती है जिसे दोनों पक्ष समझते हैं: SNOMED CT, LOINC, ICD, ATC, UCUM, RxNorm। पहचान और सुरक्षा मानक तय करते हैं कि कौन क्या पढ़ सकता है: OAuth 2.0 और SMART on FHIR, साथ ही IHE प्रोफाइल जो इन सभी को परीक्षण किए गए व्यंजनों में जोड़ते हैं। कोई भी केवल एक का उपयोग नहीं करता है; एक अस्पताल आमतौर पर एक साथ सभी चार परतों को चलाता है।
नक्शा
हेल्थकेयर इंटरऑपरेबिलिटी स्टैंडर्ड चार लेयर्स बनाते हैं। एक्सचेंज स्टैंडर्ड (HL7 v2, CDA, FHIR, DICOM और DICOMweb) सिस्टम के बीच डेटा ले जाते हैं, और IHE प्रोफाइल उन्हें टेस्टेड रेसिपी में जोड़ते हैं। openEHR स्टोर्ड रिकॉर्ड को स्ट्रक्चर करता है और OMOP रिसर्च डेटाबेस को स्ट्रक्चर करता है। SNOMED CT और LOINC जैसी टर्मिनोलॉजी, और SMART on FHIR जैसे आइडेंटिटी स्टैंडर्ड, इन सभी के अंदर उपयोग किए जाते हैं।
| परत | मानक | यह क्या है | 2026 में आप इसे कहाँ पाएंगे |
|---|---|---|---|
| एक्सचेज | HL7 v2 | MLLP पर पाइप-सीमांकित संदेश (ADT, ORU, ORM, SIU) | अस्पतालों के अंदर: प्रवेश, प्रयोगशाला परिणाम, आदेश, शेड्यूलिंग। अभी भी सबसे आम इंटरफ़ेस |
| एक्सचेज | CDA / C-CDA | मानव-पठनीय भाग और कोडित प्रविष्टियों वाले XML नैदानिक दस्तावेज़ | डिस्चार्ज सारांश, रेफरल पत्र, यूएस C-CDA, MyHealth@EU में क्रॉस-बॉर्डर सारांश |
| एक्सचेज | FHIR (R4, R4B, R5) | REST और JSON पर वेब संसाधन (Patient, Observation, Condition…) | रोगी ऐप, राष्ट्रीय API, EHR API, US Core, IPS, EHDS एक्सचेंज प्रारूप |
| एक्सचेज | DICOM और DICOMweb | एम्बेडेड मेटाडेटा के साथ छवि ऑब्जेक्ट; DICOMweb इसका REST चेहरा है | हर स्कैनर, PACS और रेडियोलॉजी व्यूअर; वेब व्यूअर DICOMweb का उपयोग करते हैं |
| रेसिपी | IHE प्रोफाइल | एक उपयोग के मामले के लिए उपरोक्त का परीक्षण किया गया संयोजन (XDS, PIX/PDQ, XCA, SWF) | अस्पतालों और क्षेत्रों के बीच दस्तावेज़ साझा करना, रोगी पहचान, रेडियोलॉजी वर्कफ़्लो |
| स्टोरेज | openEHR | रिकॉर्ड के लिए आर्किटाइप-आधारित नैदानिक डेटा मॉडल | यूरोप, स्कैंडिनेविया, ब्राजील के कुछ हिस्सों में अस्पताल और राष्ट्रीय EHR प्लेटफॉर्म |
| अनुसंधान | OMOP CDM | अवलोकन संबंधी अनुसंधान के लिए एक सामान्य संबंधपरक मॉडल | अनुसंधान नेटवर्क, वास्तविक दुनिया का सबूत, EHDS द्वितीयक उपयोग |
| शब्दावली | SNOMED CT, LOINC, ICD-10/11, ATC, RxNorm, UCUM | निष्कर्षों, परीक्षणों, निदानों, दवाओं, इकाइयों के लिए कोड | उपरोक्त सभी मानकों के अंदर |
| पहचान | OAuth 2.0, OpenID Connect, SMART on FHIR, IHE XUA | उपयोगकर्ता कौन है और ऐप क्या एक्सेस कर सकता है | हर रोगी-सामना करने वाला ऐप और हर EHR ऐप प्लेटफॉर्म |
परतें एक साथ कैसे फिट होती हैं
हेल्थकेयर इंटरऑपरेबिलिटी स्टैंडर्ड की लेयर्स एक ही वर्कफ़्लो में अपना एक काम करके एक साथ फिट होती हैं: एक HL7 v2 मैसेज लैब ऑर्डर ले जाता है, LOINC और UCUM रिजल्ट को कोड करते हैं, एक openEHR प्लेटफॉर्म उसे स्टोर करता है, एक FHIR API SMART on FHIR लॉगिन के बाद उसे पेशेंट ऐप को सर्व करता है, और एक CDA डॉक्यूमेंट उसे दूसरे हॉस्पिटल के साथ शेयर करता है।
एक रक्त परीक्षण एक दोपहर में सभी चार परतों को दिखाता है। आदेश HL7 v2 ORM संदेश (एक्सचेंज) के रूप में वार्ड से निकलता है। विश्लेषक परिणाम HL7 v2 ORU के रूप में वापस आता है, जिसमें परीक्षण LOINC में कोडित होता है और इकाई UCUM (शब्दावली) में होती है। अस्पताल इसे अपने डेटाबेस में संग्रहीत करता है, शायद एक openEHR प्लेटफॉर्म (स्टोरेज)। रोगी का ऐप इसे SMART on FHIR (पहचान) के साथ लॉग इन करने के बाद एक अवलोकन के रूप में FHIR API के माध्यम से पढ़ता है। यदि अस्पताल पूरे रिपोर्ट को दूसरे अस्पताल के साथ साझा करता है, तो यह IHE XDS रजिस्ट्री के माध्यम से CDA दस्तावेज़ के रूप में ऐसा कर सकता है। यदि परिणाम बाद में एक अनुसंधान समूह में शामिल होता है, तो इसे OMOP में परिवर्तित किया जाता है।
मानक प्रतिस्पर्धी नहीं हैं। प्रत्येक को एक अलग काम के लिए बनाया गया था, और एक को दूसरे से बदलना आमतौर पर कुछ ऐसा पुनर्निर्माण करना होता है जो पहले से ही काम कर रहा है।
आपको किसकी आवश्यकता है?
आपको किस हेल्थकेयर इंटरऑपरेबिलिटी स्टैंडर्ड की आवश्यकता है यह काम पर निर्भर करता है: पेशेंट या क्लिनिशियन ऐप्स के लिए SMART on FHIR के साथ FHIR R4, मौजूदा हॉस्पिटल सिस्टम से कनेक्ट करने के लिए HL7 v2, इमेज के लिए DICOM और DICOMweb, पूरे डॉक्यूमेंट के लिए CDA या FHIR डॉक्यूमेंट, लॉन्ग-टर्म रिकॉर्ड स्टोरेज के लिए openEHR, रिसर्च के लिए OMOP, और जब दो सिस्टम को समान व्यवहार करना होता है तो IHE प्रोफाइल।
- आप रोगियों या चिकित्सकों के लिए एक ऐप बना रहे हैं: FHIR R4, आपके बाज़ार के प्रोफाइल के साथ (कार्यान्वयन गाइड), लॉगिन के लिए SMART on FHIR।
- आप एक अस्पताल के मौजूदा सिस्टम से जुड़ रहे हैं: पहले HL7 v2 की अपेक्षा करें; जहां विक्रेता इसे प्रदान करता है वहां FHIR। HL7 v2 संदेशों की व्याख्या देखें।
- आप छवियों को संभालते हैं: स्टोरेज और ट्रांसफर के लिए DICOM, ब्राउज़र में किसी भी चीज़ के लिए DICOMweb, केवल मेटाडेटा के लिए FHIR ImagingStudy। DICOMweb की व्याख्या और ImagingStudy बनाम DICOMweb देखें।
- आप पूरे दस्तावेज़ों (सारांश, पत्र) का आदान-प्रदान करते हैं: जहां यह अनिवार्य है वहां CDA, जहां आप चुन सकते हैं वहां FHIR दस्तावेज़ (प्रकार
documentका बंडल)। CDA और C-CDA की व्याख्या देखें। - आप दशकों तक रिकॉर्ड कैसे संग्रहीत किया जाता है, इसका डिज़ाइन करते हैं: openEHR, एक्सचेंज परत के रूप में FHIR के साथ। openEHR बनाम FHIR देखें।
- आप कई रिकॉर्ड पर शोध चलाते हैं: OMOP, स्रोत के रूप में FHIR के साथ। स्वास्थ्य डेटा का द्वितीयक उपयोग देखें।
- आपको दो सिस्टम को एक ही तरह से व्यवहार करने की आवश्यकता है: अपने उपयोग के मामले के लिए IHE प्रोफ़ाइल चुनें और उसके विरुद्ध परीक्षण करें।
Anpheros कहाँ बैठता है
Anpheros Platform स्टैंडर्ड मैप की एक्सचेंज लेयर में OAuth 2.0 एक्सेस और चेंज नोटिफिकेशन्स के लिए वेबहुक के साथ एक FHIR R4 सर्वर के रूप में बैठता है, जो HL7 v2 ORU, CSV या JSON से एक कनेक्टर के माध्यम से लैब रिजल्ट प्राप्त करता है। यह DICOM इमेज स्टोर नहीं करता है और CDS Hooks सर्विस ऑफर नहीं करता है; वे हॉस्पिटल सिस्टम में रहते हैं।
Anpheros Platform एक FHIR R4 सर्वर है जिसमें रोगी-केंद्रित रिकॉर्ड की आवश्यकता वाले संसाधन (Patient, Observation, Condition, MedicationStatement, DocumentReference, DiagnosticReport, Immunization, Consent, Provenance और अन्य), एक्सेस के लिए OAuth 2.0, और परिवर्तन सूचनाओं के लिए वेबहुक हैं। प्रयोगशाला परिणाम HL7 v2 ORU, CSV या JSON से प्रयोगशाला कनेक्टर के माध्यम से आते हैं। यह DICOM छवियों को संग्रहीत नहीं करता है और CDS Hooks सेवा प्रदान नहीं करता है; वे अस्पताल के सिस्टम में रहते हैं, और रिकॉर्ड उन्हें इंगित करता है।
पढ़ने का क्रम
हेल्थकेयर इंटरऑपरेबिलिटी स्टैंडर्ड के लिए एक अच्छा रीडिंग ऑर्डर इस बात से शुरू होता है कि FHIR क्या है और यह HL7 v2 से कैसे अलग है, फिर FHIR Observation रिसोर्स, फिर उसमें उपयोग की जाने वाली LOINC और SNOMED CT टर्मिनोलॉजी, फिर इमेज के लिए DICOMweb, डॉक्यूमेंट के लिए CDA और अंत में रिकॉर्ड कैसे स्टोर किए जाते हैं, इसके लिए FHIR की तुलना में openEHR।
यदि आप इस क्षेत्र में नए हैं: FHIR क्या है → HL7 बनाम FHIR → FHIR Observation → LOINC और SNOMED CT → DICOMweb → CDA → openEHR बनाम FHIR।
संबंधित पृष्ठ
- HL7 बनाम FHIR
- HL7 v2 संदेशों की व्याख्या
- CDA और C-CDA की व्याख्या
- DICOMweb की व्याख्या
- openEHR बनाम FHIR
- FHIR कार्यान्वयन गाइड
- FHIR R4 बनाम R5
- LOINC कोड क्या है?
- SNOMED CT क्या है?
- डेवलपर्स के लिए DICOM बनाम FHIR
- FHIR प्रोफाइल और एक्सटेंशन की व्याख्या
- FHIR शब्दावली सर्वर की व्याख्या
- स्वास्थ्य डेटा विनियमन मानचित्र
- यूरोप और अमेरिका में राष्ट्रीय इलेक्ट्रॉनिक स्वास्थ्य रिकॉर्ड
- अस्पताल प्रणाली एकीकरण की व्याख्या
- चिकित्सा डेटा पर AI
- स्वास्थ्य डेटा का द्वितीयक उपयोग
- स्वास्थ्य ऐप्स में सुरक्षा और पहचान
स्रोत
- HL7 अंतर्राष्ट्रीय: मानक
- HL7 FHIR R4 विनिर्देश
- DICOM मानक, वर्तमान संस्करण
- IHE तकनीकी फ्रेमवर्क
- openEHR विनिर्देश
- OHDSI OMOP कॉमन डेटा मॉडल
- SMART ऐप लॉन्च
अक्सर पूछे जाने वाले प्रश्न
क्या FHIR अन्य सभी मानकों को बदल रहा है?
नहीं। FHIR कस्टम API को बदल रहा है और धीरे-धीरे कुछ CDA दस्तावेज़ों के आदान-प्रदान को। HL7 v2 अस्पतालों के अंदर काम का घोड़ा बना हुआ है, DICOM छवियों के लिए एकमात्र मानक बना हुआ है, और openEHR और OMOP उन सवालों (भंडारण, अनुसंधान) का जवाब देते हैं जिनके लिए FHIR डिज़ाइन नहीं किया गया था।
एक मानक और एक IHE प्रोफ़ाइल के बीच क्या अंतर है?
FHIR या DICOM जैसे मानक बिल्डिंग ब्लॉक को परिभाषित करते हैं। एक IHE प्रोफ़ाइल विशिष्ट ब्लॉक चुनता है, उनके विकल्पों को ठीक करता है और बताता है कि सिस्टम को एक कार्य के लिए उनका उपयोग कैसे करना चाहिए, ताकि दो विक्रेता जो दोनों IHE परीक्षण पास करते हैं, वे एक परियोजना के बिना एक साथ काम कर सकें।
राष्ट्रीय स्वास्थ्य प्रणालियाँ कौन सा मानक उपयोग करती हैं?
अधिकांश यूरोपीय प्रणालियों ने CDA दस्तावेज़ों और HL7 v2 के साथ शुरुआत की, और FHIR API जोड़ रही हैं; EHDS एक्सचेंज प्रारूप FHIR और IPS पर बनाया गया है। अमेरिका रोगी पहुंच के लिए FHIR US Core और दस्तावेज़ विनिमय के लिए C-CDA को अनिवार्य करता है।
SNOMED CT और LOINC कहाँ फिट होते हैं?
वे एक्सचेंज मानक नहीं हैं; वे शब्दावली हैं जिनका उपयोग उन सभी के अंदर किया जाता है। एक LOINC कोड HL7 v2 OBX सेगमेंट, एक CDA प्रविष्टि और FHIR अवलोकन में परीक्षण की पहचान करता है।
सैंडबॉक्स में मुफ़्त आज़माएँ
5 मिनट में आपकी पहली FHIR कॉल. एक HL7 FHIR R4 API जिसमें मरीज़ की सहमति शामिल है: सैंडबॉक्स में आज़माएं, फिर अपना ऐप या क्लिनिक सिस्टम कनेक्ट करें।
मुफ़्त · 30 सिंथेटिक मरीज़ · कोई कार्ड नहीं
Anpheros एक मेडिकल रिकॉर्ड बनाता है जिसे मरीज़ नियंत्रित कर सकता है और किसी भी क्लिनिक के साथ साझा कर सकता है, यह EU में स्थित HL7 FHIR R4 प्लेटफ़ॉर्म पर आधारित है। ये गाइड आपको अपने स्वास्थ्य को समझने और व्यवस्थित करने में मदद करते हैं; ये आपके डॉक्टर का विकल्प नहीं हैं।
Anpheros के बारे में →