# FHIR बनाम HL7 v2: व्यावहारिक अंतर

> डेवलपर्स के लिए HL7 v2 संदेश और FHIR संसाधन की तुलना: प्रारूप, परिवहन, दोनों में एक ही लैब परिणाम, अनुवाद की समस्याएं, और Anpheros v2 को कहाँ स्वीकार करता है।

Source: https://developers.anpheros.com/hi/guides/fhir-vs-hl7-v2

**HL7 v2 1980 के दशक के अंत से अस्पताल प्रणालियों द्वारा आदान-प्रदान किया जाने वाला संदेश प्रारूप है — पाइप-सीमांकित घटनाएँ जैसे "रोगी भर्ती हुआ" या "लैब परिणाम तैयार" नेटवर्क कनेक्शन पर सिस्टम के बीच धकेली जाती हैं — जबकि HL7 FHIR एक वेब API मानक है जहाँ एप्लिकेशन HTTPS पर JSON में Patient और Observation जैसे संसाधनों को पढ़ते और लिखते हैं।** वे ऐसे विकल्प नहीं हैं जिन्हें आप एक बार चुनते हैं: अधिकांश अस्पताल अभी भी आंतरिक रूप से v2 पर चलते हैं, नए एप्लिकेशन और रोगी-सामना करने वाले API FHIR का उपयोग करते हैं, और एकीकरण कार्य अक्सर एक को दूसरे में अनुवाद करना होता है। यह पृष्ठ उन बिंदुओं पर उनकी तुलना करता है जो कोड लिखते समय मायने रखते हैं, दोनों में एक ही डेटा दिखाता है, और बताता है कि Anpheros v2 को कहाँ स्वीकार करता है।

## साइड बाय साइड

| | HL7 v2 | HL7 FHIR R4 |
|---|---|---|
| स्टाइल | इवेंट-ट्रिगर किए गए संदेश (एडमिट, ऑर्डर, रिजल्ट) | आपके द्वारा बनाए गए, पढ़े गए, अपडेट किए गए, खोजे गए रिसोर्स |
| फॉर्मेट | लाइन ब्रेक द्वारा अलग किए गए टेक्स्ट सेगमेंट, फ़ील्ड `\|` द्वारा, कंपोनेंट `^` द्वारा | JSON (या XML) |
| ट्रांसपोर्ट | आमतौर पर अस्पताल नेटवर्क के अंदर TCP पर MLLP | HTTPS REST |
| क्वेरी | सीमित; सिस्टम ज़्यादातर पुश करते हैं | सर्च पैरामीटर, `_include`, हिस्ट्री |
| सुरक्षा | नेटवर्क-लेवल (VPN, प्राइवेट लिंक) | OAuth 2.0 / SMART on FHIR, TLS, स्कोप |
| लचीलापन | कई वैकल्पिक फ़ील्ड और लोकल Z-सेगमेंट; हर इंटरफ़ेस पर बातचीत होती है | बेस रिसोर्स प्लस प्रोफाइल (US Core, IPS, European IGs) |
| सामान्य उपयोगकर्ता | EHR, लैब, रेडियोलॉजी, अस्पताल के अंदर बिलिंग सिस्टम | ऐप्स, पेशेंट-एक्सेस API, क्रॉस-ऑर्गेनाइजेशन एक्सचेंज, AI |

सबसे आम v2 संदेश:

| संदेश | अर्थ | सबसे नज़दीकी FHIR रिसोर्स |
|---|---|---|
| ADT^A01, A03, A08 | एडमिट, डिस्चार्ज, पेशेंट अपडेट | `Patient`, `Encounter` |
| ORM / OML | टेस्ट ऑर्डर करें | `ServiceRequest` |
| ORU^R01 | रिजल्ट तैयार | `Observation`, `DiagnosticReport` |
| SIU | शेड्यूलिंग | `Appointment` |
| MDM | डॉक्यूमेंट | `DocumentReference` |

## दोनों में समान लैब परिणाम

एक ORU^R01 परिणाम लाइन (OBX सेगमेंट):

```
OBX|1|NM|2093-3^Cholesterol^LN||212|mg/dL|<200|H|||F|||20261002074500
```

वही परिणाम HL7 FHIR R4 Observation के रूप में, जैसा कि Anpheros उस संदेश को आयात करने के बाद संग्रहीत करता है:

```json
{
  "resourceType": "Observation",
  "status": "final",
  "category": [{"coding": [{"system": "http://terminology.hl7.org/CodeSystem/observation-category", "code": "laboratory"}]}],
  "code": {"coding": [{"system": "http://loinc.org", "code": "2093-3", "display": "Cholesterol [Mass/volume] in Serum or Plasma"}], "text": "Cholesterol"},
  "effectiveDateTime": "2026-10-02T07:45:00Z",
  "valueQuantity": {"value": 212.0, "unit": "mg/dL"},
  "interpretation": [{"coding": [{"system": "http://terminology.hl7.org/CodeSystem/v3-ObservationInterpretation", "code": "H"}]}],
  "referenceRange": [{"high": {"value": 200.0, "unit": "mg/dL"}}]
}
```

फ़ील्ड दर फ़ील्ड: OBX-3 `code` बन जाता है, OBX-5 और OBX-6 `valueQuantity` बन जाते हैं, OBX-7 `referenceRange`, OBX-8 `interpretation`, OBX-11 `status`, OBX-14 `effectiveDateTime`। HL7 सेगमेंट, डेटा प्रकारों और शब्दावली के लिए मैपिंग के साथ एक आधिकारिक [HL7 Version 2 to FHIR](https://build.fhir.org/ig/HL7/v2-to-fhir/) कार्यान्वयन गाइड प्रकाशित करता है।

## अनुवाद कहाँ गलत हो जाते हैं

- **समय क्षेत्र (Time zones)।** v2 टाइमस्टैम्प जैसे `20261002074500` में अक्सर कोई ऑफसेट नहीं होता; आपको प्रेषक का ज़ोन जानना होगा। FHIR में, जब भी कोई समय मौजूद होता है, तो ज़ोन की आवश्यकता होती है। (Anpheros एक अनज़ोन्ड v2 समय को UTC के रूप में पढ़ता है; यदि आपके पास ऑफसेट है तो उसे भेजें।)
- **स्थानीय कोड (Local codes)।** कई लैब LOINC के बजाय OBX-3 में अपने स्वयं के कोड डालती हैं। एक अच्छा अनुवाद स्थानीय कोड को रखता है और जब वह कर सकता है तो उसे LOINC से मैप करता है, न कि उसे छोड़ देता है।
- **बार-बार भेजना (Repeated sends)।** v2 प्रेषक टाइमआउट पर पुनः प्रसारित करते हैं। प्रति परिणाम एक स्थिर पहचानकर्ता के बिना, एक FHIR स्टोर डुप्लिकेट से भर जाता है।
- **वैकल्पिक सब कुछ (Optional everything)।** एक ही फ़ील्ड दो प्रेषकों द्वारा खाली, दोहराया या अलग तरह से उपयोग किया जा सकता है। FHIR पक्ष को मान्य करें; [FHIR R4 validator](https://developers.anpheros.com/tools/fhir-validator) दिखाता है कि अनुवादित संसाधन में क्या गायब है।
- **सुधार (Corrections)।** v2 परिणाम स्थिति `C` (सुधारित) को मौजूदा Observation को अपडेट करना चाहिए और उसका इतिहास बनाए रखना चाहिए, न कि दूसरा बनाना चाहिए।

## कब किसका उपयोग करें

- **अस्पताल के अंदर, मौजूदा सिस्टम के बीच:** v2 आमतौर पर वह भाषा है जो सिस्टम बोलते हैं। एक इंटीग्रेशन इंजन संदेशों को रूट और ट्रांसफॉर्म करता है।
- **एक ऐप, पेशेंट-एक्सेस API या कुछ भी जो संगठनों को पार करता है, उसका निर्माण:** FHIR, OAuth और सहमति के साथ।
- **AI या एनालिटिक्स को फ़ीड करना:** FHIR, क्योंकि यह क्वेरी करने योग्य, कोडित और वर्ज़न किया हुआ है।
- **दोनों:** सामान्य वास्तविक दुनिया का पैटर्न — लैब या EHR से v2 प्राप्त करें, FHIR स्टोर करें, एप्लिकेशन को FHIR सर्व करें।

## Anpheros कहाँ फिट बैठता है

Anpheros रोगी रिकॉर्ड को FHIR R4 के रूप में संग्रहीत करता है और एक HL7 v2 संदेश प्रकार स्वीकार करता है: **ORU^R01 लैब परिणाम**, जो HTTPS पर [लैब कनेक्टर](https://developers.anpheros.com/hi/guides/lab-connector) (`POST /v1/patients/{id}/labs/import` के साथ `Content-Type: x-application/hl7-v2+er7`) पर भेजे जाते हैं। प्रत्येक OBX एक प्रयोगशाला अवलोकन (Observation) बन जाता है जिसमें LOINC कोड, संदर्भ सीमा और व्याख्या शामिल होती है; रिपोर्ट आईडी को प्रोवेनेंस (provenance) में रखा जाता है और पुनः भेजे गए रिपोर्टों को छोड़ दिया जाता है। एक नया मान (value) के साथ एक सुधारा गया परिणाम (OBX-11 = `C`) को स्थिति `amended` के साथ एक नए अवलोकन के रूप में संग्रहीत किया जाता है; मूल वैसा ही रहता है, इसलिए यदि आपका स्रोत सुधार भेजता है, तो पहले वाले अवलोकन को `entered-in-error` के रूप में चिह्नित करें या FHIR API के माध्यम से इसे अपडेट करें। एक काम करने वाला उदाहरण [लैब परिणाम API](https://developers.anpheros.com/hi/guides/lab-results-api) है।

यह अन्य v2 संदेशों (ADT, ऑर्डर, शेड्यूलिंग) को स्वीकार नहीं करता है, MLLP पर नहीं सुनता है और v2 नहीं भेजता है। उनके लिए, Anpheros के सामने एक एकीकरण इंजन (integration engine) FHIR में अनुवाद करता है और API के माध्यम से लिखता है।

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

### क्या FHIR, HL7 v2 को बदल रहा है?
जल्द ही नहीं। v2 अधिकांश अस्पतालों के अंदर रीढ़ की हड्डी बना हुआ है क्योंकि यह काम करता है और मौजूदा प्रणालियों में निर्मित है। FHIR इसके चारों ओर बढ़ रहा है — ऐप्स में, रोगी पहुंच और संगठनों के बीच आदान-प्रदान में — और दोनों सह-अस्तित्व में हैं, अक्सर उनके बीच अनुवाद के साथ।

### MLLP क्या है?
मिनिमल लोअर लेयर प्रोटोकॉल: TCP कनेक्शन पर v2 संदेशों को फ्रेम करने का एक सरल तरीका, प्रत्येक संदेश के चारों ओर स्टार्ट और एंड कैरेक्टर और एक पावती (ACK) वापस। FHIR इसके बजाय HTTPS का उपयोग करता है।

### क्या मैं HL7 v2 संदेशों को स्वचालित रूप से FHIR में परिवर्तित कर सकता हूँ?
ज्यादातर। HL7 का v2-to-FHIR कार्यान्वयन गाइड मानक मैपिंग देता है, और एकीकरण इंजन उन्हें लागू करते हैं। स्थानीय कोड, Z-सेगमेंट, समय क्षेत्र और प्रत्येक प्रेषक वैकल्पिक फ़ील्ड का उपयोग कैसे करता है, इसके लिए मैन्युअल कार्य की अपेक्षा करें।

### क्या Anpheros, HL7 v2 स्वीकार करता है?
हाँ, प्रयोगशाला परिणामों के लिए: ORU^R01 संदेश HTTPS पर प्रयोगशाला कनेक्टर को पोस्ट किए जाते हैं जो FHIR Observations बन जाते हैं। अन्य v2 संदेश प्रकार और MLLP कनेक्शन समर्थित नहीं हैं।

## संबंधित

- [HL7 v2 से FHIR मैपिंग](https://developers.anpheros.com/hi/guides/hl7-v2-to-fhir-mapping): सेगमेंट और फ़ील्ड मैपिंग, और एक कन्वर्टर
- [लैब परिणाम API: HL7 v2, FHIR और LOINC](https://developers.anpheros.com/hi/guides/lab-results-api)
- [FHIR रिकॉर्ड में प्रयोगशाला परिणाम कैसे आयात करें](https://developers.anpheros.com/hi/guides/import-lab-results-fhir)
- [स्वास्थ्य सेवा डेटा इंटरऑपरेबिलिटी](https://developers.anpheros.com/hi/guides/interoperability)
- [DICOM बनाम FHIR: इमेजिंग डेटा और क्लिनिकल डेटा](https://developers.anpheros.com/hi/guides/dicom-vs-fhir)
- [FHIR प्लेटफ़ॉर्म](https://developers.anpheros.com/hi/guides/fhir)