CDA बनाम FHIR: दस्तावेज़ बनाम संसाधन, कब कौन सा उपयुक्त है, और उनके बीच रूपांतरण कैसे करें

संक्षिप्त उत्तर: CDA आपको एक दस्तावेज़ देता है: एक हस्ताक्षरित XML फ़ाइल जो एक समय में एक रोगी के बारे में होती है, जिसमें एक मानव-पठनीय कथा और एक कंप्यूटर-पठनीय प्रविष्टि होती है, जिसे पूरा और अपरिवर्तित रहना चाहिए। FHIR आपको संसाधन देता है: एक रोगी, चालीस अवलोकन, तीन स्थितियाँ, प्रत्येक का अपना URL होता है, जिसे REST API के माध्यम से स्वतंत्र रूप से प्राप्त, खोजा और अपडेट किया जा सकता है। FHIR संसाधनों को एक दस्तावेज़ (एक document प्रकार का बंडल, जो एक कंपोजीशन के नेतृत्व में होता है) में भी पैक कर सकता है, जो CDA का सीधा समकक्ष है। CDA चुनें जहाँ कोई विनियमन या भागीदार इसकी आवश्यकता हो; API, ऐप्स और किसी भी चीज़ के लिए FHIR चुनें जिसे पढ़ा जाने के बजाय क्वेरी किया जाना चाहिए।

दो आकार

CDA और FHIR के दो अलग-अलग आकार होते हैं। CDA पूरे XML दस्तावेज़ों का आदान-प्रदान करता है जो HL7 v3 डेटा प्रकारों पर बने होते हैं, जिन्हें OID द्वारा पहचाना जाता है, जिसमें अनिवार्य कथा, कोई क्वेरी नहीं, कोई अपडेट नहीं और पूरे दस्तावेज़ पर हस्ताक्षर शामिल हैं। FHIR व्यक्तिगत JSON या XML संसाधनों या बंडलों का आदान-प्रदान करता है, जिन्हें कैनोनिकल URL द्वारा पहचाना जाता है, जिसमें अंतर्निहित REST क्वेरी, संस्करणित अपडेट और कार्यान्वयन गाइड में प्रकाशित प्रोफाइल शामिल हैं।

व्यवहार में अंतर का क्या मतलब है

व्यवहार में CDA और FHIR के बीच अंतर यह है कि CDA एक बार लिखे गए और पूरे संरक्षित किए गए कंटेंट के लिए उपयुक्त है, जैसे कि हस्ताक्षरित डिस्चार्ज सारांश, जबकि FHIR ऐसे डेटा के लिए उपयुक्त है जो बढ़ता है और क्वेरी किया जाता है, जैसे कि रक्तचाप श्रृंखला। CDA रिसीवर प्रदर्शित कर सकता है लेकिन आयात करने के लिए सामंजस्य स्थापित करना चाहिए; FHIR रिसीवर को ऐसे संसाधन मिलते हैं जो पहले से ही उसके अपने रिकॉर्ड की तरह आकार के होते हैं।

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

एक और व्यावहारिक अंतर यह है कि प्राप्तकर्ता क्या कर सकता है। एक CDA प्राप्तकर्ता हमेशा दस्तावेज़ प्रदर्शित कर सकता है; इसकी प्रविष्टियों को आयात करने के लिए सुलह की आवश्यकता होती है, अनुभाग दर अनुभाग। एक FHIR प्राप्तकर्ता ऐसे संसाधन प्राप्त करता है जो पहले से ही उसके अपने रिकॉर्ड के आकार में हैं; कठिन प्रश्न पहचान (क्या यह वही रोगी है?) और उत्पत्ति (किसने यह कब दावा किया?) पर चले जाते हैं। रोगी मिलान देखें।

FHIR दस्तावेज़: मिलन बिंदु

एक FHIR दस्तावेज़ type: "document" वाला एक बंडल है जिसका पहला प्रविष्टि एक कंपोजीशन है। कंपोजीशन CDA हेडर और अनुभाग सूची की भूमिका निभाता है: प्रकार (LOINC), दिनांक, लेखक, विषय, संरक्षक, स्थिति, और section[] जिसमें एक शीर्षक, एक कोड, कथा पाठ और डेटा ले जाने वाले संसाधनों के संदर्भ होते हैं।

{
  "resourceType": "Bundle",
  "type": "document",
  "identifier": {"system": "urn:ietf:rfc:3986", "value": "urn:uuid:3f2d7a3e-…"},
  "timestamp": "2026-03-14T10:15:00+01:00",
  "entry": [
    {"fullUrl": "urn:uuid:comp-1", "resource": {
      "resourceType": "Composition", "status": "final",
      "type": {"coding": [{"system": "http://loinc.org", "code": "60591-5", "display": "Patient summary Document"}]},
      "subject": {"reference": "urn:uuid:pat-1"},
      "date": "2026-03-14T10:15:00+01:00",
      "author": [{"reference": "urn:uuid:prac-1"}],
      "title": "Patient summary",
      "section": [{
        "title": "Allergies and intolerances",
        "code": {"coding": [{"system": "http://loinc.org", "code": "48765-2"}]},
        "text": {"status": "generated", "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p>Penicillin: rash</p></div>"},
        "entry": [{"reference": "urn:uuid:allergy-1"}]
      }]
    }},
    {"fullUrl": "urn:uuid:pat-1", "resource": {"resourceType": "Patient", "id": "pat-1"}},
    {"fullUrl": "urn:uuid:prac-1", "resource": {"resourceType": "Practitioner", "id": "prac-1"}},
    {"fullUrl": "urn:uuid:allergy-1", "resource": {"resourceType": "AllergyIntolerance", "id": "allergy-1", "patient": {"reference": "urn:uuid:pat-1"}, "code": {"coding": [{"system": "http://snomed.info/sct", "code": "764146007", "display": "Penicillin"}]}}}
  ]
}

अंतर्राष्ट्रीय रोगी सारांश ठीक यही है: एक FHIR दस्तावेज़ प्रोफ़ाइल, उन प्रणालियों के लिए एक CDA ट्विन के साथ जिन्हें अभी भी इसकी आवश्यकता है। FHIR बंडल समझाया भी देखें।

उनके बीच रूपांतरण

CDA और FHIR के बीच रूपांतरण सीमाओं के साथ दोनों दिशाओं में काम करता है। FHIR कार्यान्वयन गाइड पर HL7 C-CDA दस्तावेज़ प्रकारों, अनुभागों और प्रविष्टियों को कंपोजीशन प्रोफाइल और संसाधनों पर मैप करता है; केवल कथा वाले अनुभाग डेटा के बिना टेक्स्ट बन जाते हैं। FHIR से CDA उन संसाधनों के लिए काम करता है जो C-CDA टेम्प्लेट में फिट होते हैं। किसी भी दिशा में, मूल को Provenance के साथ DocumentReference के रूप में रखा जाना चाहिए।

• CDA → FHIR: HL7 FHIR पर C-CDA कार्यान्वयन गाइड अमेरिकी दस्तावेज़ प्रकारों और अनुभागों को कंपोजीशन प्रोफाइल में मैप करता है; प्रविष्टियाँ संसाधनों में मैप होती हैं (Problem Concern Act → Condition, Medication Activity → MedicationStatement, Result Observation → Observation)। मैपिंग अच्छी तरह से टेम्पलेट किए गए लेवल 3 सामग्री के लिए नियतात्मक है और केवल कथा अनुभागों के लिए हानिपूर्ण है, जो डेटा के बिना पाठ बन जाते हैं।
• FHIR → CDA: उन दस्तावेज़ों के लिए संभव है जिनके संसाधन C-CDA टेम्पलेट्स में फिट होते हैं। फ्री-फॉर्म FHIR संसाधन जिन्हें कभी दस्तावेज़ के रूप में नहीं माना गया था (पहनने योग्य अवलोकनों की एक धारा) एक समझदार CDA नहीं बनते हैं।
• मूल को रखें। आप जिस भी दिशा में परिवर्तित करते हैं, स्रोत को वैसे ही स्टोर करें जैसे वह प्राप्त हुआ था, एक DocumentReference के रूप में, और Provenance को परिवर्तित संसाधनों से उस पर इंगित करने दें। रूपांतरण एक दृश्य है, प्रतिस्थापन नहीं।

जब CDA अभी भी सही उत्तर है

CDA अभी भी सही उत्तर है जब प्राप्त करने वाला पक्ष इसकी आवश्यकता होती है (यूएस ट्रांज़िशन ऑफ़ केयर, MyHealth@EU पेशेंट समरी और ePrescription, कई राष्ट्रीय दस्तावेज़ रजिस्ट्री), जब कंटेंट कानूनी रूप से एक दस्तावेज़ होता है जिस पर हस्ताक्षर किए जाने और पूरे संरक्षित किए जाने की आवश्यकता होती है, या जब पार्टनर का इंफ्रास्ट्रक्चर IHE XDS होता है, जो संसाधनों के बजाय दस्तावेज़ों को इंडेक्स करता है। अन्यथा, FHIR से शुरुआत करें।

जब प्राप्त करने वाला पक्ष इसकी आवश्यकता हो (अमेरिका में देखभाल का संक्रमण, MyHealth@EU रोगी सारांश और ई-प्रिस्क्रिप्शन आज, कई राष्ट्रीय दस्तावेज़ रजिस्ट्रियां); जब सामग्री कानूनी रूप से एक दस्तावेज़ हो जिस पर हस्ताक्षर किया जाना चाहिए और जिसे पूरा संरक्षित किया जाना चाहिए; जब भागीदार का बुनियादी ढांचा IHE XDS हो, जो दस्तावेज़ों को इंडेक्स करता है, संसाधनों को नहीं। हर दूसरे मामले में, FHIR से शुरू करें और जहाँ दस्तावेज़ की आवश्यकता हो, वहाँ FHIR दस्तावेज़ उत्पन्न करें।

संबंधित पृष्ठ

• CDA और C-CDA समझाया
• FHIR बंडल समझाया
• अंतर्राष्ट्रीय रोगी सारांश
• HL7 बनाम FHIR
• DocumentReference बनाम DiagnosticReport बनाम Binary
• रोगी मिलान

स्रोत

• HL7 FHIR R4: दस्तावेज़
• HL7 FHIR R4: कंपोजीशन
• FHIR पर HL7 C-CDA कार्यान्वयन गाइड
• HL7 FHIR: CDA के साथ तुलना (परिशिष्ट)
• HL7 अंतर्राष्ट्रीय रोगी सारांश IG

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

क्या FHIR दस्तावेज़ सिर्फ JSON में CDA है?

नहीं। यह सिद्धांतों (पूरा, हस्ताक्षरित, मानव-पठनीय, हेडर के साथ) को साझा करता है लेकिन इसकी सामग्री सामान्य FHIR संसाधन हैं, इसलिए वही अवलोकन एक दस्तावेज़ में रह सकता है और API द्वारा परोसा जा सकता है। CDA में, एक प्रविष्टि केवल उसके दस्तावेज़ के अंदर मौजूद होती है।

क्या मैं FHIR दस्तावेज़ पर हस्ताक्षर कर सकता हूँ?

हाँ। Bundle.signature बंडल पर एक डिजिटल हस्ताक्षर रखता है, और IPS और राष्ट्रीय गाइड बताते हैं कि कैसे। व्यवहार में कई परिनियोजन हस्ताक्षर के बजाय परिवहन सुरक्षा और उत्पत्ति पर भरोसा करते हैं।

क्या FHIR में templateId है?

समकक्ष meta.profile है, जो स्ट्रक्चरडेफिनिशन के कैनोनिकल URL की एक सूची है जिसे संसाधन अनुरूप होने का दावा करता है। वैलिडेटर उसी तरह अनुरूपता की जांच करते हैं जैसे CDA स्कीमेट्रॉन टेम्पलेट्स की जांच करते हैं।

एक नए राष्ट्रीय कार्यक्रम को कौन सा चुनना चाहिए?

हाल के कार्यक्रमों (EHDS विनिमय प्रारूप, अमेरिकी रोगी पहुंच नियम, IPS) ने FHIR को चुना है, सारांश और पत्रों के लिए FHIR दस्तावेज़ों के साथ, और केवल पुराने भागीदारों के लिए एक CDA पथ बनाए रखा है।

Anpheros Platform

सैंडबॉक्स में मुफ़्त आज़माएँ

5 मिनट में आपकी पहली FHIR कॉल. एक HL7 FHIR R4 API जिसमें मरीज़ की सहमति शामिल है: सैंडबॉक्स में आज़माएं, फिर अपना ऐप या क्लिनिक सिस्टम कनेक्ट करें।

मुफ़्त सैंडबॉक्स बनाएँडेवलपर गाइड पढ़ें →

मुफ़्त · 30 सिंथेटिक मरीज़ · कोई कार्ड नहीं

द्वारा लिखित

Anpheros टीम

Anpheros एक मेडिकल रिकॉर्ड बनाता है जिसे मरीज़ नियंत्रित कर सकता है और किसी भी क्लिनिक के साथ साझा कर सकता है, यह EU में स्थित HL7 FHIR R4 प्लेटफ़ॉर्म पर आधारित है। ये गाइड आपको अपने स्वास्थ्य को समझने और व्यवस्थित करने में मदद करते हैं; ये आपके डॉक्टर का विकल्प नहीं हैं।

Anpheros के बारे में →