स्टैंडर्ड्स

CDA और C-CDA को समझना: HL7 v2 और FHIR के बीच HL7 क्लिनिकल डॉक्यूमेंट स्टैंडर्ड

HL7 CDA क्लिनिकल डॉक्यूमेंट्स के लिए एक XML स्टैंडर्ड है जिसे इंसान पढ़ सकते हैं और कंप्यूटर प्रोसेस कर सकते हैं। CDA डॉक्यूमेंट में क्या होता है (हेडर, सेक्शन, नैरेटिव, कोडेड एंट्रीज़), इसके तीन लेवल, US कंसॉलिडेटेड CDA क्या जोड़ता है, 2026 में CDA कहाँ अनिवार्य है, और यह FHIR से कैसे संबंधित है।

Anpheros द्वारा लिखा गया, स्रोतों सहित
जानकारी, चिकित्सा सलाह नहीं
डेटा EU में संग्रहीत

द्वारा Anpheros प्रकाशित 26 अक्टूबर 2026 7 मिनट पढ़ें

संक्षिप्त उत्तर: क्लिनिकल डॉक्यूमेंट आर्किटेक्चर (CDA) क्लिनिकल दस्तावेज़ों के लिए HL7 का मानक है: डिस्चार्ज सारांश, रेफरल पत्र, परामर्श नोट्स, रोगी सारांश। एक CDA दस्तावेज़ एक XML फ़ाइल है जिसमें एक हेडर (कौन, कब, किसके बारे में) और अनुभागों का मुख्य भाग होता है, प्रत्येक में मानव-पठनीय कथा और, वैकल्पिक रूप से, मशीन-पठनीय कोडित प्रविष्टियाँ होती हैं। C-CDA (कंसोलिडेटेड CDA) अमेरिकी कार्यान्वयन गाइड है जो सबसे आम दस्तावेज़ प्रकारों के लिए टेम्प्लेट को ठीक करता है; CCD (कंटिन्यूटी ऑफ़ केयर डॉक्यूमेंट) इसका सबसे प्रसिद्ध सदस्य है। CDA रिलीज़ 2 2005 से है और अभी भी कई राष्ट्रीय और सीमा-पार कार्यक्रमों में अनिवार्य है।

एक दस्तावेज़ कैसा दिखता है

एक CDA दस्तावेज़ एक XML फ़ाइल होती है जिसमें एक ClinicalDocument रूट होता है, जिसमें एक हेडर (LOINC कोड के रूप में दस्तावेज़ का प्रकार, templateId OIDs, एक id, प्रभावी समय, गोपनीयता कोड, रोगी, लेखक और कस्टोडियन) और अनुभागों का एक मुख्य भाग होता है, प्रत्येक में एक LOINC कोड, एक अनिवार्य मानव-पठनीय पाठ तत्व और सॉफ़्टवेयर के पढ़ने के लिए वैकल्पिक कोडेड प्रविष्टियाँ होती हैं।

<ClinicalDocument xmlns="urn:hl7-org:v3">
  <typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>
  <templateId root="2.16.840.1.113883.10.20.22.1.2" extension="2015-08-01"/>
  <id root="2.16.840.1.113883.19.5" extension="DOC-2026-0314"/>
  <code code="34133-9" codeSystem="2.16.840.1.113883.6.1" displayName="Summarization of Episode Note"/>
  <effectiveTime value="20260314101500+0100"/>
  <confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25"/>
  <recordTarget><patientRole>…</patientRole></recordTarget>
  <author>…</author>
  <custodian>…</custodian>
  <component><structuredBody>
    <component><section>
      <templateId root="2.16.840.1.113883.10.20.22.2.6.1" extension="2015-08-01"/>
      <code code="48765-2" codeSystem="2.16.840.1.113883.6.1" displayName="Allergies and adverse reactions"/>
      <title>Allergies</title>
      <text><table><tr><td>Penicillin</td><td>Rash</td></tr></table></text>
      <entry>…coded Allergy Concern Act…</entry>
    </section></component>
  </structuredBody></component>
</ClinicalDocument>

ध्यान देने योग्य तीन बातें। दस्तावेज़ प्रकार और प्रत्येक अनुभाग को एक LOINC कोड (34133-9, 48765-2) द्वारा पहचाना जाता है। टेम्प्लेट को OID (2.16.840.1…) द्वारा पहचाना जाता है, URL द्वारा नहीं। <text> तत्व अनिवार्य है और वही है जो एक चिकित्सक देखता है; <entry> वैकल्पिक है और वही है जो सॉफ़्टवेयर पढ़ता है।

तीन स्तर

CDA संरचना के तीन स्तर परिभाषित करता है। स्तर 1 एक मान्य हेडर है जिसमें एक असंरचित मुख्य भाग होता है, जैसे कि एक एम्बेडेड PDF। स्तर 2 में कोडेड अनुभागों और कथा के साथ एक संरचित मुख्य भाग जोड़ा जाता है, लेकिन कोई कोडेड प्रविष्टियाँ नहीं होती हैं। स्तर 3 टेम्पलेट्स का पालन करते हुए कोडेड प्रविष्टियाँ जोड़ता है, ताकि सॉफ़्टवेयर एलर्जी, दवाएं और समस्याएं आयात कर सके। अधिकांश वास्तविक दस्तावेज़ स्तर 2 और 3 के बीच में होते हैं।

स्तर 1: एक मान्य हेडर प्लस एक असंरचित मुख्य भाग, उदाहरण के लिए एक एम्बेडेड PDF। कानूनी तौर पर एक CDA दस्तावेज़; कंप्यूटर इसे फ़ाइल कर सकते हैं लेकिन पढ़ नहीं सकते।
स्तर 2: कोडित अनुभागों और कथा के साथ संरचित मुख्य भाग, कोई कोडित प्रविष्टियाँ नहीं। सॉफ़्टवेयर जानता है कि एक एलर्जी अनुभाग है; यह एलर्जी की सूची नहीं बना सकता।
स्तर 3: टेम्प्लेट का पालन करने वाली कोडित प्रविष्टियों वाले अनुभाग। सॉफ़्टवेयर प्राप्त रिकॉर्ड में एलर्जी, दवाएं और समस्याएं आयात कर सकता है।

अधिकांश वास्तविक दुनिया CDA स्तर 2 और 3 के बीच बैठता है: कुछ अनुभाग कोडित होते हैं, अन्य केवल कथा होते हैं।

छह सिद्धांत जो इसे अभी भी आकार देते हैं

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

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

C-CDA: अमेरिकी समेकन

C-CDA (Consolidated CDA) अमेरिकी कार्यान्वयन गाइड है जिसने 2011 से, कई ओवरलैपिंग CDA गाइड को एक में मिला दिया, जिसमें लगभग एक दर्जन दस्तावेज़ टेम्पलेट हैं जैसे कि Continuity of Care Document, Discharge Summary और Referral Note, और अनुभाग और प्रविष्टि टेम्पलेट्स की एक साझा लाइब्रेरी। ONC प्रमाणन के लिए C-CDA R2.1 की आवश्यकता देखभाल के संक्रमण और रोगी सारांश के लिए होती है।

2011 से पहले, अमेरिकी कार्यान्वयनकर्ताओं ने कई ओवरलैपिंग CDA गाइड का उपयोग किया। कंसोलिडेटेड CDA ने उन्हें एक में विलय कर दिया, जिसमें लगभग एक दर्जन दस्तावेज़ टेम्प्लेट (कंटिन्यूटी ऑफ़ केयर डॉक्यूमेंट, डिस्चार्ज समरी, प्रोग्रेस नोट, रेफरल नोट, केयर प्लान, ऑपरेटिव नोट, डायग्नोस्टिक इमेजिंग रिपोर्ट और अन्य) और अनुभाग और प्रविष्टि टेम्प्लेट की एक साझा लाइब्रेरी थी। C-CDA R2.1 अमेरिकी EHR प्रमाणन (ONC) द्वारा देखभाल के संक्रमण और रोगी सारांश के लिए आवश्यक है, और APIs के लिए FHIR US Core के साथ-साथ बना हुआ है।

2026 में CDA कहाँ रहता है

2026 में CDA अमेरिका में प्रदाता-से-प्रदाता आदान-प्रदान में C-CDA के रूप में Direct messaging और स्वास्थ्य सूचना आदान-प्रदान के माध्यम से, यूरोप के क्रॉस-बॉर्डर MyHealth@EU रोगी सारांश और ePrescription में, राष्ट्रीय कार्यक्रमों जैसे जर्मनी के eArztbrief और ePA, ऑस्ट्रिया के ELGA, इटली के FSE, नीदरलैंड और स्विट्जरलैंड में, और हर जगह स्कैन किए गए या PDF दस्तावेज़ों के चारों ओर लिपटे हेडर के रूप में मौजूद है।

संयुक्त राज्य अमेरिका: प्रदाताओं के बीच दस्तावेज़ विनिमय के लिए C-CDA, डायरेक्ट मैसेजिंग और स्वास्थ्य सूचना एक्सचेंजों में।
यूरोप, सीमा-पार: MyHealth@EU रोगी सारांश और ePrescription को CDA दस्तावेज़ों (eHDSI टेम्प्लेट) के रूप में आदान-प्रदान करता है, EHDS के तहत FHIR-आधारित प्रारूप आ रहे हैं। यूरोपीय संघ की सीमाओं के पार ई-प्रिस्क्रिप्शन देखें।
राष्ट्रीय कार्यक्रम: जर्मनी का इलेक्ट्रॉनिक डॉक्टर का पत्र (eArztbrief) और ePA के हिस्से, ऑस्ट्रिया के ELGA दस्तावेज़, इटली के FSE, नीदरलैंड और स्विट्जरलैंड दस्तावेज़ों के लिए CDA का उपयोग करते हैं, अक्सर IHE XDS रजिस्ट्रियों के माध्यम से।
हर जगह: एक CDA हेडर में लिपटे स्कैन किए गए और PDF दस्तावेज़, ताकि एक दस्तावेज़ रजिस्ट्री उन्हें अनुक्रमित कर सके।

एक प्राप्तकर्ता को वास्तव में क्या मिलता है

एक CDA दस्तावेज़ का प्राप्तकर्ता हमेशा एक पठनीय कथा प्राप्त करता है, लेकिन कोडेड डेटा वह केवल तभी आयात कर सकता है जब प्रेषक ने स्तर 3 टेम्पलेट्स का लगातार उपयोग किया हो। प्राप्त करने वाली प्रणालियाँ आम तौर पर कथा प्रदर्शित करती हैं और प्रविष्टियों से समस्याओं, दवाओं और एलर्जी को एक-एक करके सुलझाने की पेशकश करती हैं, क्योंकि विभिन्न विक्रेताओं के दो स्तर 3 दस्तावेज़ शायद ही कभी एक ही तथ्य को समान रूप से कोड करते हैं।

एक CDA दस्तावेज़ पढ़ने के लिए विश्वसनीय है और आयात करने के लिए असमान है। कथा हमेशा मौजूद होती है; कोडित प्रविष्टियाँ प्रेषक के स्तर और टेम्प्लेट अनुशासन पर निर्भर करती हैं। प्राप्त करने वाली प्रणालियाँ आमतौर पर चिकित्सक को कथा दिखाती हैं और प्रविष्टियों से समस्याओं, दवाओं और एलर्जी को स्थानीय रिकॉर्ड में, एक-एक करके "सुलह" करने की पेशकश करती हैं। वह सुलह कदम मौजूद है क्योंकि विभिन्न विक्रेताओं से दो स्तर 3 दस्तावेज़ शायद ही कभी एक ही तथ्य को एक ही तरह से कोड करते हैं।

Anpheros में, एक अस्पताल से एक CDA दस्तावेज़ को वैसे ही संग्रहीत किया जाता है, जैसे वह है, एक DocumentReference के रूप में जिसमें XML संलग्न है, और इसकी कोडित सामग्री, जहाँ मौजूद है, FHIR संसाधनों (Condition, AllergyIntolerance, MedicationStatement) में मैप की जाती है, जिसमें उत्पत्ति दस्तावेज़ पर वापस इंगित करती है। DocumentReference बनाम DiagnosticReport बनाम Binary देखें।

स्रोत

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

क्या CDA HL7 v3 के समान है?

CDA HL7 v3 संदर्भ सूचना मॉडल पर बनाया गया है और v3 डेटा प्रकारों का उपयोग करता है, यही कारण है कि इसका XML वैसा दिखता है जैसा वह दिखता है। HL7 v3 मैसेजिंग के बाकी हिस्सों को बहुत कम अपनाया गया; CDA v3 का वह हिस्सा है जो सफल रहा।

CCD क्या है?

कंटिन्यूटी ऑफ़ केयर डॉक्यूमेंट रोगी सारांश के लिए C-CDA दस्तावेज़ प्रकार है: समस्याएं, दवाएं, एलर्जी, टीकाकरण, परिणाम, प्रक्रियाएं, महत्वपूर्ण संकेत, देखभाल योजना। यह अंतर्राष्ट्रीय रोगी सारांश का अमेरिकी समकक्ष है।

क्या CDA को FHIR द्वारा प्रतिस्थापित किया जा रहा है?

नए API और ऐप्स के लिए, हाँ; संस्थानों के बीच दस्तावेज़ विनिमय के लिए, धीरे-धीरे। अमेरिका और यूरोप में नियम अभी भी विशिष्ट दस्तावेज़ों के लिए CDA की आवश्यकता होती है, और FHIR दस्तावेज़ों को इसके बजाय साथ-साथ पेश किया जा रहा है।

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

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

Anpheros Platform

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

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

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

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

यह गाइड केवल जानकारी के लिए है और चिकित्सा सलाह का विकल्प नहीं है। अपने स्वास्थ्य संबंधी निर्णयों के लिए, अपने डॉक्टर से बात करें। आपात स्थिति में अपने स्थानीय आपातकालीन नंबर पर कॉल करें (यूरोप में 112)।

द्वारा लिखित

Anpheros टीम

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

Anpheros के बारे में →