3.8 इंटरऑपरेबिलिटी और ओपन स्टैंडर्ड

अवलोकन और उद्देश्य

इंटरऑपरेबिलिटी दो या अधिक सिस्टम की वह क्षमता है जिससे वे सूचना का आदान-प्रदान कर सकें और आदान-प्रदान की गई सूचना का उपयोग कर सकें, बिना किसी पक्ष को दूसरे के आंतरिक कामकाज को जाने। एक ओपन स्टैंडर्ड एक ऐसा विनिर्देश (specification) है जो सार्वजनिक रूप से उपलब्ध हो, पारदर्शी और सहमति-आधारित प्रक्रिया से विकसित और अनुरक्षित हो, और जिसे लागू करना निःशुल्क (या निष्पक्ष, उचित और गैर-भेदभावपूर्ण) हो, ताकि कोई भी बिना किसी एक विक्रेता की अनुमति के अनुरूप सिस्टम बना सके। इंटरऑपरेबिलिटी के लिए डिज़ाइन करने का अर्थ है ऐसे सिस्टम बनाना जो इन साझा, प्रकाशित विनिर्देशों के माध्यम से जुड़ें, न कि कस्टम इंटीग्रेशन (bespoke integrations) के माध्यम से: एकबारगी, विशेष रूप से बनाए गए कनेक्टर जो ठीक दो सिस्टम को जोड़ते हैं और जिन्हें किसी भी पक्ष के बदलने पर फिर से बनाना पड़ता है।

एक बड़े संगठन के लिए, इंटरऑपरेबिलिटी कोई विलासिता नहीं है। यह वह आधार है जिस पर बाकी सब कुछ चलता है। उद्यम कंपनियाँ अधिग्रहित करते हैं, विक्रेता बदलते हैं, और दर्जनों आंतरिक और तृतीय-पक्ष सिस्टम को आपस में जोड़ते हैं, और ओपन स्टैंडर्ड ही वे साधन हैं जो किसी नए घटक को बिना पुनर्लेखन के फिट होने देते हैं। सरकार के लिए दांव और भी ऊँचे हैं। सार्वजनिक सेवाएँ कई एजेंसियों, सरकार के स्तरों, और निजी आपूर्तिकर्ताओं में वितरित की जाती हैं, और पूरे तंत्र पर किसी एक निकाय का नियंत्रण नहीं होता। लाभ के लिए आवेदन करने वाला एक नागरिक विभिन्न विभागों के स्वामित्व वाले पहचान, कर, स्वास्थ्य, और कल्याण सिस्टम को छू सकता है। इन सिस्टम को आपस में इंटरऑपरेट करना ही होगा, अन्यथा सेवा विफल हो जाती है। सार्वजनिक निकाय वर्षों में मापे जाने वाले खरीद चक्रों पर भी आपूर्तिकर्ता बदलते हैं, इसलिए किसी एक विक्रेता के प्रोप्राइटरी इंटरफ़ेस पर निर्भरता एक लंबा, महँगा जाल बन जाती है।

आवर्ती विफलता का तरीका इंटरऑपरेबिलिटी के विपरीत है: प्रोप्राइटरी लॉक-इन, जहाँ किसी संगठन का डेटा और प्रक्रियाएँ किसी एक विक्रेता के गैर-मानक स्वरूपों और इंटरफ़ेस से इतनी उलझी होती हैं कि बाद में स्विच करना, एकीकृत करना, या डेटा पढ़ना भी निषेधात्मक रूप से महँगा हो जाता है। ओपन स्टैंडर्ड इसके विरुद्ध प्राथमिक बचाव हैं। यह अध्याय उन स्तरों को कवर करता है जिन पर सिस्टम को इंटरऑपरेट करना चाहिए, वे स्टैंडर्ड जो इसे संभव बनाते हैं, और इसके लिए डिज़ाइन, खरीद, और प्रमाणन कैसे करें। यह API और इंटरफ़ेस डिज़ाइन (अध्याय 2.3), वितरित सिस्टम (अध्याय 3.3), डेटा रणनीति और गवर्नेंस (अध्याय 7.1), खरीद और ओपन सोर्स (अध्याय 10.3), और अनुपालन तथा गवर्नेंस (अध्याय 4.6) से निकटता से जुड़ता है।

मुख्य सिद्धांत

इंटरऑपरेबिलिटी डिज़ाइन में शामिल की जाती है, बाद में जोड़ी नहीं जाती। निर्माण से पहले स्टैंडर्ड तय करें, क्योंकि बाद में उन्हें जोड़ने का मतलब है इंटरफ़ेस को फिर से लिखना और डेटा को माइग्रेट करना।
कस्टम इंटीग्रेशन की तुलना में ओपन स्टैंडर्ड को प्राथमिकता दें। एक अनुरूप इंटरफ़ेस हर वर्तमान और भविष्य के भागीदार की सेवा करता है; एक कस्टम कनेक्टर केवल एक की सेवा करता है।
इंटरऑपरेबिलिटी के स्तर होते हैं। तार के पार बाइट्स पहुँचाना (तकनीकी) बेकार है यदि दोनों पक्ष इस बात पर सहमत नहीं हैं कि बाइट्स का अर्थ क्या है (सिमेंटिक)।
अर्थ साझा शब्दावलियों में रहता है। पहचानकर्ता, कोड सिस्टम, और शब्दावली ही वे चीज़ें हैं जो आदान-प्रदान किए गए डेटा को केवल प्रसारित करने योग्य नहीं बल्कि उपयोग करने योग्य बनाती हैं।
स्टैंडर्ड तभी वास्तविक हैं जब आप उनका अनुपालन करते हैं। बिना अनुरूपता परीक्षण (conformance testing) के ”FHIR का समर्थन करता है” का दावा मार्केटिंग है, इंटरऑपरेबिलिटी नहीं।
लॉक-इन एक कुल स्वामित्व लागत (total-cost-of-ownership) का निर्णय है। आज का सस्ता प्रोप्राइटरी विकल्प अक्सर कल का महँगा फँसा हुआ तंत्र बन जाता है।
सरकार आवश्यकता को कई गुना बढ़ा देती है। सार्वजनिक सेवाएँ संगठनात्मक सीमाओं में फैली होती हैं जिन पर किसी का नियंत्रण नहीं होता, इसलिए ओपन स्टैंडर्ड अक्सर एक विकल्प नहीं बल्कि अनिवार्यता होते हैं।

सिफ़ारिशें

इंटरऑपरेबिलिटी के सभी चार स्तरों के लिए डिज़ाइन करें

यूरोपीय इंटरऑपरेबिलिटी फ्रेमवर्क और संबंधित मॉडल चार स्तरों का वर्णन करते हैं, और वास्तव में इंटरऑपरेट करने के लिए किसी सिस्टम को इन सभी को संतुष्ट करना होगा। तकनीकी इंटरऑपरेबिलिटी प्लंबिंग है: नेटवर्क, प्रोटोकॉल, और ट्रांसपोर्ट (उदाहरण के लिए HTTPS) जो सिस्टम के बीच बाइट्स को स्थानांतरित करते हैं। सिंटैक्टिक इंटरऑपरेबिलिटी संरचना और स्वरूप पर सहमति है, संदेश का व्याकरण, जैसे JSON (JavaScript Object Notation, एक हल्का टेक्स्ट डेटा स्वरूप) या XML (eXtensible Markup Language)। सिमेंटिक इंटरऑपरेबिलिटी अर्थ पर सहमति है: कि gender लेबल वाला फ़ील्ड या 250.00 कोड दोनों पक्षों के लिए एक ही चीज़ का अर्थ रखता है। संगठनात्मक इंटरऑपरेबिलिटी प्रक्रियाओं, गवर्नेंस, भूमिकाओं, और कानूनी समझौतों का संरेखण है: किसको किसे क्या भेजने की अनुमति है, किस डेटा-साझाकरण समझौते के तहत, और किस उद्देश्य के लिए। अधिकांश इंटीग्रेशन परियोजनाएँ पहले दो स्तरों में सफल होती हैं और तीसरे और चौथे में विफल होती हैं। सिमेंटिक और संगठनात्मक इंटरऑपरेबिलिटी को प्रथम-श्रेणी डिज़ाइन कार्य मानें, बाद का विचार नहीं।

डेटा-एक्सचेंज और API परत को मानकीकृत करें

सिस्टम के इंटरफ़ेस का वर्णन और उद्भासन कैसे किया जाए, इसके लिए ओपन, व्यापक रूप से लागू किए गए स्टैंडर्ड अपनाएँ। वेब API (Application Programming Interfaces, वह परिभाषित संविदा जिसके माध्यम से एक सिस्टम दूसरे को कॉल करता है) के लिए, OpenAPI Specification का उपयोग करें, जो एक REST (Representational State Transfer) API का विक्रेता-निरपेक्ष, मशीन-पठनीय विवरण है, जो इंटरफ़ेस को दस्तावेज़ भी करता है और क्लाइंट कोड, सर्वर, टेस्ट, तथा मॉक्स भी उत्पन्न करता है। पेलोड स्वरूपों के लिए, अपनी व्यापकता और मानव-पठनीयता के लिए JSON को प्राथमिकता दें, और XML का उपयोग वहाँ करें जहाँ कोई इकोसिस्टम पहले से इस पर मानकीकृत है। जहाँ आपको सेवाओं के बीच उच्च-प्रदर्शन, दृढ़ता से टाइप की गई संचार की आवश्यकता हो, वहाँ Protocol Buffers (Protobuf) के साथ gRPC (एक रिमोट-प्रोसीजर-कॉल फ्रेमवर्क) पर विचार करें, जो एक सुसंहत, स्कीमा-परिभाषित बाइनरी स्वरूप है, और स्वयं एक ओपन विनिर्देश है। बात विशिष्ट तकनीक की नहीं है। बात यह है कि संविदा प्रकाशित, मशीन-पठनीय, और स्वतंत्र रूप से लागू करने योग्य हो। इंटरफ़ेस डिज़ाइन की गहराई के लिए अध्याय 2.3 देखें।

अपने डोमेन के लिए मान्यता प्राप्त स्टैंडर्ड अपनाएँ

अधिकांश क्षेत्रों ने डोमेन-विशिष्ट इंटरऑपरेबिलिटी स्टैंडर्ड पर सहमति बना ली है। अपना स्वयं का आविष्कार करने के बजाय इनका उपयोग करें। स्वास्थ्य सेवा अग्रणी उदाहरण है। HL7 (Health Level Seven, एक स्टैंडर्ड निकाय और इसके पुराने संदेश स्टैंडर्ड) को नए कार्य के लिए काफ़ी हद तक FHIR (Fast Healthcare Interoperability Resources) ने प्रतिस्थापित कर दिया है, जो एक आधुनिक स्टैंडर्ड है जो क्लिनिकल अवधारणाओं (मरीज़, अवलोकन, दवा) को JSON या XML का उपयोग करते हुए REST API के माध्यम से आदान-प्रदान किए गए वेब संसाधनों के रूप में मॉडल करता है। वित्त में, ISO 20022 संरचित, समृद्ध रूप से एनोटेट किए गए भुगतान और वित्तीय संदेश के लिए ओपन स्टैंडर्ड है, जिसे अब दुनिया भर के भुगतान सिस्टम ने अपनाया है। भू-स्थानिक डेटा में, OGC (Open Geospatial Consortium) मानचित्र और फ़ीचर सेवाओं के लिए WMS और WFS जैसे स्टैंडर्ड प्रकाशित करता है। अन्य उदाहरणों में व्यावसायिक दस्तावेज़ों के लिए OASIS और UBL, और निर्माण के लिए IFC (BuildingSMART) शामिल हैं। मान्यता प्राप्त स्टैंडर्ड चुनने से अनुरूप टूल, आपूर्तिकर्ताओं, और प्रशिक्षित कर्मचारियों का पूरा इकोसिस्टम मिलता है।

पहचानकर्ताओं, कोड सिस्टम, और ऑन्टोलॉजी में अर्थ को एंकर करें

सिमेंटिक इंटरऑपरेबिलिटी के लिए साझा शब्दावलियों की आवश्यकता होती है। मानक पहचानकर्ता (identifiers) का उपयोग करें ताकि एक ही वास्तविक-जगत की चीज़ का संदर्भ हर जगह समान हो (उदाहरण के लिए एक ISO देश कोड, किसी कानूनी संस्था के लिए LEI, या एक राष्ट्रीय मरीज़ पहचानकर्ता)। मुक्त टेक्स्ट के बजाय प्रकाशित कोड सिस्टम और शब्दावलियों (परिभाषित अर्थों वाले कोडित अवधारणाओं की नियंत्रित सूचियाँ) का उपयोग करें: क्लिनिकल शब्दों के लिए SNOMED CT और LOINC, निदान के लिए ICD (International Classification of Diseases), टेक्स्ट के लिए Unicode। जहाँ अवधारणाओं के बीच संबंध महत्वपूर्ण हों, वहाँ RDF और OWL (W3C Web Ontology Language) जैसे स्टैंडर्ड में व्यक्त ऑन्टोलॉजी (अवधारणाओं और उनके परस्पर संबंध का एक औपचारिक, मशीन-पठनीय मॉडल) का उपयोग करें। इन शब्दावलियों का गवर्नेंस एक डेटा-गवर्नेंस ज़िम्मेदारी है; अध्याय 7.1 देखें।

पॉइंट-टू-पॉइंट वायरिंग के बजाय स्टैंडर्ड-आधारित पैटर्न के माध्यम से इंटीग्रेट करें

ऐसे आर्किटेक्चरल पैटर्न को प्राथमिकता दें जो इंटीग्रेशन की संख्या को कॉम्बिनेटोरियल के बजाय रैखिक बनाए रखें। N सिस्टम जो पॉइंट-टू-पॉइंट जुड़े हों, उन्हें N×(N−1)/2 तक कस्टम कनेक्टर की आवश्यकता हो सकती है। वही N सिस्टम जो प्रत्येक किसी साझा स्टैंडर्ड का अनुपालन करते हों, उस स्टैंडर्ड के केवल N कार्यान्वयनों की आवश्यकता होती है। गेटवे, प्रकाशित API संविदाओं, और कैनोनिकल डेटा मॉडल का उपयोग करें ताकि एक नया भागीदार हर मौजूदा सिस्टम के बजाय स्टैंडर्ड के विरुद्ध केवल एक बार इंटीग्रेट हो। यह लॉक-इन का भी प्रतिकारक है: क्योंकि संविदा खुली है, किसी विक्रेता को उससे जुड़े हर किसी को छुए बिना बदला जा सकता है।

अनुरूपता और प्रमाणन की आवश्यकता रखें

एक स्टैंडर्ड तभी मूल्य प्रदान करता है जब कार्यान्वयन वास्तव में उसका अनुपालन करते हैं। प्रकाशित परीक्षण सूट और वैलिडेटर (उदाहरण के लिए FHIR के वैलिडेटर और Touchstone टेस्टिंग, या आपके बिल्ड पाइपलाइन में OpenAPI स्कीमा वैलिडेशन) का उपयोग करते हुए अनुरूपता परीक्षण (conformance testing) (स्वचालित जाँच कि कोई कार्यान्वयन विनिर्देश को पूरा करता है) पर ज़ोर दें। जहाँ कोई औपचारिक प्रमाणन (certification) कार्यक्रम मौजूद हो (एक स्वतंत्र निकाय जो अनुरूपता प्रमाणित करता है, जैसा कि राष्ट्रीय स्वास्थ्य-आईटी प्रमाणन योजनाओं में होता है), प्रमाणित उत्पादों को प्राथमिकता दें और अनुबंधों में प्रमाणन की आवश्यकता रखें। अनुरूपता जाँच को सतत एकीकरण में शामिल करें, ताकि स्टैंडर्ड से विचलन उत्पादन में सामने आने के बजाय बिल्ड को विफल कर दे।

ट्रेड-ऑफ़: फ़ायदे और नुकसान

दृष्टिकोण	फ़ायदे	नुकसान / लागत
ओपन स्टैंडर्ड	कई आपूर्तिकर्ता, कोई लॉक-इन नहीं, इकोसिस्टम टूल, भविष्य के भागीदार सस्ते में इंटीग्रेट होते हैं	स्टैंडर्ड व्यापक/जटिल हो सकता है, नीश फीचर अपनाने में धीमा, समिति की गति से विकास
कस्टम पॉइंट-टू-पॉइंट इंटीग्रेशन	पहले कनेक्शन के लिए तेज़, सटीक फिट, न्यूनतम प्रारंभिक सीखना	लागत कॉम्बिनेटोरियल रूप से बढ़ती है, भंगुर, हर बदलाव पर फिर से किया जाता है, लॉक-इन को जन्म देता है
प्रोप्राइटरी विक्रेता स्वरूप/API	समृद्ध फीचर, विक्रेता समर्थन, एक इकोसिस्टम के भीतर तेज़ शुरुआत	लॉक-इन, स्विचिंग लागत, बाद में डेटा निकालना कठिन, मूल्य निर्धारण की शक्ति विक्रेता की ओर स्थानांतरित होती है
डोमेन स्टैंडर्ड (FHIR, ISO 20022)	साझा अर्थ, प्रशिक्षित कार्यबल, नियामक-संरेखित	सीखने की प्रक्रिया, लेगेसी डेटा की मैपिंग, वर्ज़निंग और प्रोफ़ाइल प्रबंधन का ओवरहेड

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

अपनी टीम के साथ चर्चा करने योग्य प्रश्न

संगठनात्मक इंटरऑपरेबिलिटी (डेटा-साझाकरण समझौते, सहमति मॉडल, और प्रक्रिया संरेखण) का स्वामी कौन है, जिस पर आपका तकनीकी इंटीग्रेशन निर्भर करता है? अधिकांश परियोजनाएँ तकनीकी और सिंटैक्टिक स्तरों में सफल होती हैं और संगठनात्मक स्तर पर अटक जाती हैं: बाइट्स आते हैं और पार्स होते हैं, लेकिन कोई समझौता यह नियंत्रित नहीं करता कि किसे क्या भेजने की अनुमति है, किस उद्देश्य के लिए, किस सहमति के तहत। सरकार में एक नागरिक का डेटा उन एजेंसियों में जाता है जो अपने-अपने सिस्टम की स्वामी हैं और अलग-अलग कानूनी आधारों के प्रति जवाबदेह हैं, इसलिए एक परफेक्ट FHIR इंटरफ़ेस तब तक बेकार है जब तक साझाकरण समझौता और सहमति मॉडल मौजूद न हो। अपना सबसे महत्वपूर्ण क्रॉस-बाउंड्री एक्सचेंज लाएँ और प्रत्येक पक्ष पर कानूनी साधन और जवाबदेह स्वामी का नाम बताएँ, न कि केवल API का। यदि वह स्वामी अनाम है, तो इंटीग्रेशन हर तकनीकी परीक्षण पास कर जाएगा और फिर भी उत्पादन में अवरुद्ध रहेगा। इन समझौतों को संदेश स्कीमा जितनी ही कठोरता के साथ डिज़ाइन कलाकृतियों के रूप में मानें।
आप किसी स्टैंडर्ड के प्रोप्राइटरी एक्सटेंशन पर कितनी भारी निर्भरता रखते हैं, और क्या कोई अन्य अनुरूप कार्यान्वयन अभी भी आपसे बात कर सकता है? स्टैंडर्ड में एस्केप हैच होते हैं, और उनका अत्यधिक उपयोग वास्तव में एक ओपन बैज पहने हुए लॉक-इन है: आप FHIR या ISO 20022 का दावा करते हैं लेकिन कोई भी स्वतंत्र विक्रेता वास्तव में आपकी बोली के साथ इंटरऑपरेट नहीं कर सकता। यह एक-एक करके उचित लगने वाले कस्टमाइज़ेशन के साथ रेंग कर आता है, यही कारण है कि एक बड़े तंत्र को इसे जानबूझकर मापना चाहिए। एक वास्तविक संदेश लाएँ और गिनें कि इसका कितना अर्थ मानक फ़ील्ड पर बनाम कस्टम एक्सटेंशन पर सवार है; कस्टम हिस्सा जितना अधिक होगा, आपकी पोर्टेबिलिटी उतनी ही कमज़ोर होगी और मौजूदा विक्रेता की मूल्य निर्धारण शक्ति उतनी ही मज़बूत होगी। निजी एक्सटेंशन की तुलना में स्टैंडर्ड के नियमों के भीतर प्रोफ़ाइलिंग करने और कमियों को स्टैंडर्ड में वापस योगदान करने को प्राथमिकता दें। ओपन रास्ते की पूरी बात यह है कि किसी विक्रेता को उससे जुड़े हर किसी को छुए बिना बदला जा सकता है, और एक्सटेंशन चुपचाप इसे कमज़ोर करते हैं।
आप प्रत्येक स्टैंडर्ड के किस संस्करण और प्रोफ़ाइल पर हैं, और पूरे तंत्र में उस विकल्प का गवर्नेंस कौन करता है? “स्टैंडर्ड का समर्थन करता है” संस्करण और प्रोफ़ाइल अनुशासन के बिना निरर्थक है, क्योंकि दो सिस्टम दोनों FHIR या ISO 20022 का दावा कर सकते हैं और फिर भी बात नहीं कर पाते यदि वे अलग-अलग संस्करण या प्रोफ़ाइल लागू करते हैं। कई आपूर्तिकर्ताओं और लंबे खरीद चक्रों वाले एक बड़े संगठन में, संस्करण चुपचाप एक-दूसरे से दूर होते जाते हैं जब तक कोई इंटीग्रेशन टूट न जाए। हर इंटरफ़ेस, उसके स्टैंडर्ड, उसके संस्करण, और उसकी प्रोफ़ाइल की एक इन्वेंट्री लाएँ, और नाम बताएँ कि उन्हें संरेखित रखने और अपग्रेड की योजना बनाने के लिए कौन जवाबदेह है। पाइपलाइन में अनुरूपता परीक्षणों में संस्करण और प्रोफ़ाइल को शामिल करें ताकि विचलन उत्पादन में सामने आने के बजाय बिल्ड को विफल कर दे। इस गवर्नेंस के बिना, नाममात्र रूप से अनुरूप सिस्टम अभी भी इंटरऑपरेट नहीं कर सकते, जो ठीक वही विफलता है जिसे ओपन स्टैंडर्ड रोकने के लिए बनाए गए थे।
जब कोई अनुबंध या आपूर्तिकर्ता कहता है “स्टैंडर्ड का समर्थन करता है”, तो कौन सा स्वतंत्र परीक्षण वास्तव में इसे साबित करता है, और वह परीक्षण कहाँ चलता है? बिना किसी परीक्षण के अनुरूपता का दावा मार्केटिंग है, और यह सबसे खराब जगह पर विफल होता है: उत्पादन में, पैसा बदल जाने और सिस्टम लाइव होने के बाद। कई आपूर्तिकर्ताओं से खरीदने वाले बड़े संगठन के लिए, प्रलोभन एक प्रश्नावली पर एक चेकबॉक्स स्वीकार करने का होता है, क्योंकि वैलिडेट की गई अनुरूपता पर ज़ोर देने से खरीद धीमी होती है और बोलीदाताओं का पूल संकुचित होता है। आप जिस हर स्टैंडर्ड पर निर्भर हैं, उसके लिए प्रकाशित वैलिडेटर या टेस्ट सूट (उदाहरण के लिए FHIR वैलिडेटर और Touchstone, या OpenAPI स्कीमा वैलिडेशन) लाएँ, इसके माध्यम से चलाए गए वास्तविक संदेशों का एक नमूना, और अपने अनुबंध का वह खंड जो स्वीकृति और भुगतान को इसे पास करने से जोड़ता है। प्रतिस्पर्धी खिंचाव गति बनाम प्रमाण का है: एक प्रमाणित उत्पाद अधिक महँगा हो सकता है और ऑनबोर्ड होने में अधिक समय ले सकता है, लेकिन एक असत्यापित उत्पाद विफलता को आपकी इंटीग्रेशन टीम पर स्थानांतरित कर देता है। सरकार और नियमित सेटिंग्स में, जहाँ राष्ट्रीय स्वास्थ्य-आईटी या भुगतान प्रमाणन योजनाएँ मौजूद हैं, अनुबंध में प्रमाणन की आवश्यकता रखें और सतत एकीकरण में वैलिडेटर को जोड़ें ताकि विचलन बिल्ड को विफल कर दे, क्योंकि एक ऐसा दावा जिसे आपने कभी परीक्षण नहीं किया वह एक देयता है जिसे आप ऑडिट या आउटेज के दौरान खोजेंगे।
आपके कितने इंटीग्रेशन अभी भी पॉइंट-टू-पॉइंट हैं, और उन्हें उसी तरह छोड़ने की वास्तविक कॉम्बिनेटोरियल लागत क्या है? कस्टम एक-से-एक कनेक्टर पहले लिंक के लिए बनाने में सबसे तेज़ चीज़ हैं और पूरे तंत्र में रखने के लिए सबसे महँगी चीज़, क्योंकि गिनती N×(N−1)/2 की ओर बढ़ती है जबकि एक साझा स्टैंडर्ड को केवल N कार्यान्वयनों की आवश्यकता होती है। एक बड़े संगठन में यह फैलाव एक-एक करके उचित लगने वाले निर्णयों के साथ बढ़ता जाता है जब तक इंटीग्रेशन मैप अप्रबंधनीय न हो जाए और हर सिस्टम बदलाव दर्जन भर भंगुर कनेक्टर के माध्यम से लहरें फैलाए। पॉइंट-टू-पॉइंट बनाम स्टैंडर्ड-आधारित के रूप में वर्गीकृत अपने इंटीग्रेशन की एक इन्वेंट्री लाएँ, अपने पिछले प्रमुख सिस्टम प्रतिस्थापन से प्रभावित कनेक्टर की संख्या, और कस्टम लिंक बनाए रखने में लगने वाले इंजीनियरिंग समय का अनुमान। तनाव यह है कि लाइव पॉइंट-टू-पॉइंट वायरिंग को गेटवे या कैनोनिकल मॉडल के पीछे माइग्रेट करना बिना किसी तत्काल फीचर लाभ के वास्तविक काम है, इसलिए जब तक कोई इसकी वहन लागत का परिमाणीकरण नहीं करता, यह रोडमैप में पीछे रह जाता है। दशकों तक जीवित रहने वाले और लगातार भागीदार जोड़ने वाले उद्यम और सरकारी प्लेटफ़ॉर्म के लिए, पॉइंट-टू-पॉइंट रास्ता एक धीमा कर है; इंटीग्रेशन आर्किटेक्चर के लिए एक स्वामी और हर मौजूदा सिस्टम के बजाय नए भागीदारों को स्टैंडर्ड के माध्यम से रूट करने की योजना का नाम बताएँ।
आप कहाँ अर्थ को मुक्त टेक्स्ट के रूप में व्यक्त कर रहे हैं जिसे किसी प्रकाशित कोड सिस्टम या शब्दावली को वहन करना चाहिए, और उन शब्दावलियों का गवर्नेंस कौन करता है? सिमेंटिक इंटरऑपरेबिलिटी वह जगह है जहाँ अधिकांश इंटीग्रेशन चुपचाप विफल हो जाते हैं: बाइट्स आते हैं और पार्स होते हैं, लेकिन एक अनियंत्रित स्ट्रिंग के रूप में संग्रहीत निदान, मुद्रा, या देश भेजने वाले के लिए एक चीज़ का अर्थ रखता है और प्राप्तकर्ता के लिए कुछ सूक्ष्म रूप से अलग। एक बड़े संगठन के लिए, लागत तब तक अदृश्य रहती है जब तक रिपोर्टिंग, विश्लेषण, या कोई नियामक यह उजागर नहीं करता कि एक ही अवधारणा को तीन सिस्टम में तीन तरीकों से कोडित किया गया था। वर्तमान में मुक्त टेक्स्ट के रूप में रखे गए फ़ील्ड के उदाहरण लाएँ, वे मानक पहचानकर्ता और कोड सिस्टम जो उन्हें प्रतिस्थापित कर सकते हैं (क्लिनिकल डेटा के लिए SNOMED CT और LOINC, देशों और मुद्राओं के लिए ISO कोड, कानूनी संस्थाओं के लिए LEI), और वे त्रुटि दरें या मिलान प्रयास जिन्हें मुक्त टेक्स्ट छिपा रहा है। प्रतिस्पर्धी विचार यह है कि लेगेसी डेटा को नियंत्रित शब्दावलियों में मैप करना कष्टसाध्य है और कभी प्रदर्शित नहीं किया जाता, इसलिए यह ट्रांसपोर्ट परत की तुलना में पुराने से कम-वित्तपोषित रहता है। सरकार में, जहाँ एक नागरिक का रिकॉर्ड कई स्वतंत्र सिस्टम से एकत्रित किया जाता है और एक बेमेल कोड किसी लाभ को नकार सकता है या स्वास्थ्य रिकॉर्ड को भ्रष्ट कर सकता है, शब्दावली गवर्नेंस को एक नामित डेटा-गवर्नेंस ज़िम्मेदारी (अध्याय 7.1) के रूप में मानें, न कि हर टीम पर छोड़े गए एक कार्यान्वयन विवरण के रूप में।

क्षेत्र लेंस

स्टार्टअप। गति जीतती है, और ओपन स्टैंडर्ड ही वह तरीका है जिससे एक छोटी टीम कई कनेक्टर बनाए बिना कई ग्राहकों तक पहुँचती है। वे स्वरूप बोलें जो हर भागीदार पहले से समर्थित करता है (साइन-इन के लिए OAuth, शेड्यूलिंग के लिए iCalendar, इवेंट के लिए वेबहुक, OpenAPI संविदा पर JSON) ताकि एक इंटीग्रेशन हज़ारों ग्राहकों तक पहुँचे और एक विक्रेता की अदला-बदली केवल एक एडैप्टर को छुए। अपना स्वयं का स्वरूप आविष्कार करने या प्रत्येक ग्राहक के स्टैक को हाथ से जोड़ने से बचें; यह भविष्य का रखरखाव है जिसे आप स्टाफ़ नहीं दे सकते। स्टैंडर्ड रास्ता शुरुआत में थोड़ा अधिक महँगा पड़ता है और उस बाज़ार में स्विचिंग को सस्ता रखता है जिसकी आप अभी भविष्यवाणी नहीं कर सकते।

छोटा व्यवसाय। बिना किसी इंटीग्रेशन विशेषज्ञ और सीमित बजट के, इंटरऑपरेबिलिटी को एक निर्माण परियोजना के बजाय एक खरीद निर्णय के रूप में मानें। उन टूल को प्राथमिकता दें जो पहले से ही आपके क्षेत्र के ओपन स्टैंडर्ड बोलते हैं और एक दस्तावेज़ित API उद्भासित करते हैं, ताकि आपके आपूर्तिकर्ता बदलने पर आपका डेटा पोर्टेबल बना रहे। हस्ताक्षर करने से पहले किसी संभावित विक्रेता से पूछें कि आप अपना डेटा कैसे और किस स्वरूप में बाहर और अंदर ला सकते हैं, क्योंकि आज का सस्ता प्रोप्राइटरी विकल्प कल का फँसा हुआ तंत्र है। आप स्वयं शायद ही कभी अनुरूपता परीक्षण चलाएँगे, इसलिए ऐसे उत्पादों पर निर्भर रहें जो प्रमाणित हों या व्यापक रूप से इंटरऑपरेबल हों।

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

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

उदाहरण

स्टार्टअप। एक टीम-उत्पादकता ऐप बनाने वाला एक छोटा स्टार्टअप कस्टम कनेक्टर के बजाय ओपन स्टैंडर्ड के माध्यम से अपने ग्राहकों के मौजूदा टूल से जुड़ता है: साइन-इन के लिए OAuth, शेड्यूलिंग के लिए iCalendar, और इवेंट के लिए वेबहुक। क्योंकि यह वे स्वरूप बोलता है जो हर कैलेंडर और पहचान प्रदाता पहले से समर्थित करता है, एक इंटीग्रेशन एक के बजाय हज़ारों ग्राहकों तक पहुँचता है, और बाद में किसी भुगतान या ईमेल विक्रेता की अदला-बदली केवल एक एडैप्टर को छूती है। यदि इसने हर ग्राहक के स्टैक के लिए एक कस्टम लिंक हाथ से बनाया होता, तो हर नया ग्राहक लिखने और बनाए रखने के लिए एक और कनेक्टर का मतलब होता।

उद्यम (एंटरप्राइज़)। एक बहुराष्ट्रीय बैंक अपने सीमा-पार भुगतान को एक लेगेसी प्रोप्राइटरी संदेश स्वरूप से ISO 20022 में माइग्रेट करके आधुनिक बनाता है। क्योंकि स्टैंडर्ड मुक्त टेक्स्ट के बजाय संरचित, समृद्ध रूप से एनोटेट किया गया डेटा (भुगतानकर्ता, प्राप्तकर्ता, उद्देश्य, नियामक फ़ील्ड) वहन करता है, धोखाधड़ी स्क्रीनिंग, मिलान, और रिपोर्टिंग के लिए डाउनस्ट्रीम सिस्टम दर्जन भर कस्टम पार्सर के बजाय एक कैनोनिकल स्वरूप का उपभोग करते हैं। जब बैंक बाद में अपने भुगतान-गेटवे विक्रेता को बदलता है, नया आपूर्तिकर्ता पहले से ही ISO 20022 बोलता है, इसलिए बदलाव गेटवे को छूता है, न कि इसके पीछे के सौ सिस्टम को। ओपन स्टैंडर्ड ने एक विक्रेता माइग्रेशन को एक बहु-वर्षीय पुनर्निर्माण से एक सीमित प्रतिस्थापन में बदल दिया।

सरकार। एक राष्ट्रीय स्वास्थ्य सेवा को अस्पतालों, क्लीनिकों, प्रयोगशालाओं, और एक मरीज़-सामना करने वाले ऐप (जिसे दो दशकों में विभिन्न आपूर्तिकर्ताओं द्वारा बनाया गया) से रिकॉर्ड को सुरक्षित रूप से साझा करने की आवश्यकता है। यह डेटा एक्सचेंज के लिए FHIR अनिवार्य करती है: हर सिस्टम मरीज़, अवलोकन, और दवा डेटा को मानक पहचानकर्ताओं (एक राष्ट्रीय मरीज़ ID) और क्लिनिकल शब्दावलियों (स्थितियों के लिए SNOMED CT, प्रयोगशाला परिणामों के लिए LOINC) का उपयोग करते हुए REST API पर FHIR संसाधनों के रूप में उद्भासित करता है, ताकि कोड हर जगह एक ही अर्थ रखें। आपूर्तिकर्ताओं को जुड़ने से पहले FHIR अनुरूपता वैलिडेशन पास करना होगा और राष्ट्रीय स्वास्थ्य-आईटी प्रमाणन रखना होगा। एक नया क्लिनिक सिस्टम हर मौजूदा सिस्टम के लिए कस्टम लिंक बनाने के बजाय FHIR स्टैंडर्ड के विरुद्ध केवल एक बार इंटीग्रेट होता है, और एक नागरिक कई स्वतंत्र सिस्टम से एकत्रित एक एकीकृत रिकॉर्ड देख सकता है। संगठनात्मक इंटरऑपरेबिलिटी को डेटा-साझाकरण समझौतों के माध्यम से संभाला जाता है जो नियंत्रित करते हैं कि किसे क्या और क्यों एक्सेस करने की अनुमति है, अनुपालन दायित्वों को पूरा करते हुए (अध्याय 4.6)।

व्यावसायिक मामला: प्रेरणाएँ, ROI, और TCO

ओपन स्टैंडर्ड के लिए वित्तीय तर्क पहले इंटीग्रेशन के मूल्य टैग के बारे में नहीं, बल्कि सिस्टम के जीवनकाल में कुल स्वामित्व लागत (TCO) के बारे में एक तर्क है। कस्टम इंटीग्रेशन लागत कनेक्शनों की संख्या के साथ बढ़ती है और हर बदलाव पर फिर से चुकाई जाती है। स्टैंडर्ड-आधारित इंटीग्रेशन लागत प्रति भागीदार एक बार चुकाई जाती है और पूरे तंत्र में परिशोधित की जाती है। निवेश पर प्रतिफल (ROI) कम इंटीग्रेशन श्रम, नए भागीदारों और आपूर्तिकर्ताओं के तेज़ ऑनबोर्डिंग, विक्रेताओं के कम प्रदर्शन करने पर कम स्विचिंग लागत, और उस शास्त्रीय लॉक-इन कर से बचाव के रूप में दिखाई देता है जहाँ एकमात्र आपूर्तिकर्ता कीमतें बढ़ाता है क्योंकि कोई प्रतिस्पर्धी बोली नहीं लगा सकता।

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

एंटी-पैटर्न और नुकसान

तकनीकी इंटरऑपरेबिलिटी को पूरा काम समझ लेना। संदेश आता है और पार्स होता है, लेकिन दोनों पक्ष इस बात पर असहमत हैं कि किसी फ़ील्ड का अर्थ क्या है, इसलिए डेटा चुपचाप गलत होता है।
केवल नाम में “स्टैंडर्ड-आधारित”। एक उत्पाद किसी स्टैंडर्ड का समर्थन करने का दावा करता है लेकिन कभी अनुरूपता परीक्षण पास नहीं किया और व्यवहार में भिन्न होता है।
मुक्त टेक्स्ट जहाँ कोड सिस्टम मौजूद है। निदान, मुद्राओं, या देशों को अनियंत्रित स्ट्रिंग के रूप में संग्रहीत करना सिमेंटिक इंटरऑपरेबिलिटी को नष्ट करता है।
प्रोप्राइटरी एक्सटेंशन जो स्टैंडर्ड को निगल लेते हैं। किसी स्टैंडर्ड के एस्केप हैच का इतना भारी उपयोग करना कि कोई अन्य कार्यान्वयन इंटरऑपरेट न कर सके: एक ओपन बैज पहने हुए वास्तविक लॉक-इन।
पॉइंट-टू-पॉइंट फैलाव। हर बार एक और कस्टम कनेक्टर जोड़ना, जब तक कि इंटीग्रेशन मैप एक अप्रबंधनीय कॉम्बिनेटोरियल गड़बड़ न बन जाए।
संस्करण और प्रोफ़ाइल अराजकता। किसी स्टैंडर्ड का कौन सा संस्करण या प्रोफ़ाइल उपयोग में है, इसका कोई गवर्नेंस नहीं, इसलिए नाममात्र रूप से अनुरूप सिस्टम अभी भी बात नहीं कर सकते।
संगठनात्मक इंटरऑपरेबिलिटी को नज़रअंदाज़ करना। परफेक्ट तकनीकी एक्सचेंज अवरुद्ध है क्योंकि कोई डेटा-साझाकरण समझौता, सहमति मॉडल, या प्रक्रिया संरेखण मौजूद नहीं है।
अपना स्वयं का स्टैंडर्ड बनाना। जब एक परिपक्व, अपनाया गया डोमेन स्टैंडर्ड पहले से मौजूद हो, तो एक कस्टम स्वरूप का आविष्कार करना, और इसके सभी रखरखाव को हमेशा के लिए अपने ऊपर लेना।

परिपक्वता मॉडल

स्तर 1: आरंभ (Initiate)। इंटीग्रेशन तदर्थ और पॉइंट-टू-पॉइंट है। स्वरूप प्रोप्राइटरी या अदस्तावेज़ीकृत हैं। अर्थ मुक्त टेक्स्ट और जनजातीय ज्ञान के माध्यम से व्यक्त किया जाता है। किसी भी सिस्टम या विक्रेता को बदलना एक बड़ी परियोजना है। लॉक-इन व्यापक और काफ़ी हद तक अपरिचित है।
स्तर 2: विकास (Develop)। JSON या XML जैसे सामान्य स्वरूप दिखाई देते हैं, और कुछ API दस्तावेज़ीकृत हैं, लेकिन अभ्यास टीम-दर-टीम भिन्न होता है। इंटरऑपरेबिलिटी अभी भी मुख्य रूप से सिंटैक्टिक है; सिमेंटिक सहमति असंगत और प्रति-परियोजना है। स्टैंडर्ड प्रतिक्रियात्मक रूप से चुने जाते हैं, और अनुरूपता का दावा किया जाता है लेकिन परीक्षण नहीं किया जाता।
स्तर 3: मानकीकरण (Standardize)। ओपन डेटा-एक्सचेंज स्टैंडर्ड (OpenAPI, और FHIR या ISO 20022 जैसे प्रासंगिक डोमेन स्टैंडर्ड) पूरे संगठन में दस्तावेज़ीकृत और अनिवार्य हैं। साझा पहचानकर्ता, कोड सिस्टम, और शब्दावलियाँ सिमेंटिक इंटरऑपरेबिलिटी प्रदान करते हैं। अनुरूपता परीक्षण डिलीवरी पाइपलाइन का हिस्सा है, और इंटीग्रेशन पॉइंट-टू-पॉइंट वायरिंग के बजाय स्टैंडर्ड-आधारित पैटर्न का अनुसरण करता है।
स्तर 4: प्रबंधन (Manage)। इंटरऑपरेबिलिटी को बेसलाइन के विरुद्ध मापा और नियंत्रित किया जाता है। मेट्रिक्स ट्रैक और समीक्षा किए जाते हैं: स्टैंडर्ड-आधारित बनाम पॉइंट-टू-पॉइंट इंटीग्रेशन का हिस्सा, मानक फ़ील्ड बनाम प्रोप्राइटरी एक्सटेंशन पर सवार संदेश अर्थ का अनुपात, पाइपलाइन में अनुरूपता-परीक्षण पास दरें, पूरे तंत्र में संस्करण और प्रोफ़ाइल विचलन, और एक नए भागीदार को ऑनबोर्ड करने के लिए इंटीग्रेशन लीड टाइम और दोष दरें। संस्करणों और प्रोफ़ाइलों को गवर्न किया जाता है, आपूर्तिकर्ताओं से प्रमाणन की आवश्यकता होती है और उसे सत्यापित किया जाता है, और लॉक-इन जोखिम का परिमाणीकरण किया जाता है, न कि केवल महसूस किया जाता है। किसी इंटरफ़ेस को अपनाने, अपग्रेड करने, या सेवानिवृत्त करने के निर्णय इस साक्ष्य पर आधारित होते हैं।
स्तर 5: संयोजन (Orchestrate)। इंटरऑपरेबिलिटी को लगातार सुधारा और पूरे संगठन में एकीकृत किया जाता है। संगठनात्मक इंटरऑपरेबिलिटी (समझौते, सहमति, प्रक्रिया संरेखण) को तकनीकी परतों के साथ-साथ व्यवस्थित रूप से संभाला जाता है, संगठन उन स्टैंडर्ड में वापस योगदान देता है जिन पर वह निर्भर है, और पोर्टेबिलिटी एक स्थायी डिज़ाइन बाधा है। जैसे-जैसे स्टैंडर्ड विकसित होते हैं और भागीदार जुड़ते या छोड़ते हैं, तंत्र अनुकूलित होता है, घटना के बजाय मापे गए साक्ष्य पर इंटीग्रेशन आर्किटेक्चर और शब्दावली गवर्नेंस को पुनर्संतुलित करते हुए।

चर्चा के लिए विचार

आपके सबसे महत्वपूर्ण डेटा एक्सचेंज के लिए, चार स्तरों (तकनीकी, सिंटैक्टिक, सिमेंटिक, संगठनात्मक) में से यह आज सबसे कमज़ोर किस पर है?
यदि आपके प्राथमिक विक्रेता ने नवीनीकरण पर अपनी कीमत दोगुनी कर दी, तो स्विच करने में कितना समय और कितना खर्च लगेगा, और यह ऐसा क्यों है?
आपके कौन से इंटीग्रेशन पॉइंट-टू-पॉइंट हैं, और उन्हें एक साझा ओपन स्टैंडर्ड के पीछे स्थानांतरित करने के लिए क्या चाहिए?
आप कहाँ मुक्त टेक्स्ट संग्रहीत कर रहे हैं जिसे एक प्रकाशित कोड सिस्टम या शब्दावली प्रतिस्थापित कर सकती है, और मुक्त टेक्स्ट कौन सी त्रुटियाँ छिपाता है?
क्या आपके अनुबंधों में “स्टैंडर्ड का समर्थन करता है” के लिए एक स्वतंत्र अनुरूपता या प्रमाणन परीक्षण पास करना आवश्यक है, या इसका केवल दावा किया जाता है?
कौन से ओपन-स्टैंडर्ड अनिवार्यताएँ (राष्ट्रीय या क्षेत्रीय) पहले से आप पर लागू होती हैं, और क्या आप वास्तव में उन्हें पूरा कर रहे हैं या केवल दावा कर रहे हैं?

मुख्य निष्कर्ष

इंटरऑपरेबिलिटी का अर्थ है आदान-प्रदान की गई सूचना का उपयोग करना, न कि केवल उसे प्रसारित करना; सभी चार स्तरों के लिए डिज़ाइन करें: तकनीकी, सिंटैक्टिक, सिमेंटिक, और संगठनात्मक।
कस्टम इंटीग्रेशन और प्रोप्राइटरी स्वरूपों की तुलना में ओपन, प्रकाशित, स्वतंत्र रूप से लागू करने योग्य स्टैंडर्ड को प्राथमिकता दें, जो लॉक-इन और कॉम्बिनेटोरियल लागत को जन्म देते हैं।
API और डेटा-एक्सचेंज परत को मानकीकृत करें (OpenAPI, JSON/XML, gRPC/Protobuf) और अपने डोमेन का मान्यता प्राप्त स्टैंडर्ड अपनाएँ (स्वास्थ्य में FHIR, वित्त में ISO 20022, भू-स्थानिक में OGC)।
साझा पहचानकर्ताओं, कोड सिस्टम, शब्दावलियों, और ऑन्टोलॉजी में अर्थ को एंकर करें; सिमेंटिक इंटरऑपरेबिलिटी वह जगह है जहाँ अधिकांश इंटीग्रेशन चुपचाप विफल होते हैं।
अनुरूपता परीक्षण की आवश्यकता रखें और, जहाँ उपलब्ध हो, प्रमाणन की; एक स्टैंडर्ड तभी वास्तविक है जब कार्यान्वयन प्रदर्शनीय रूप से अनुरूप हों।
चुनाव को सिस्टम के जीवनकाल में कुल स्वामित्व लागत और वैकल्पिकता पर आँकें; दीर्घजीवी, बहु-पक्षीय प्लेटफ़ॉर्म (लगभग सभी उद्यम और सरकारी सिस्टम) के लिए, ओपन स्टैंडर्ड जीतते हैं, और सरकार उन्हें तेज़ी से अनिवार्य कर रही है।

संदर्भ और आगे पढ़ना

HL7 International, FHIR (Fast Healthcare Interoperability Resources) specification (hl7.org/fhir)
ISO 20022, Universal financial industry message scheme (iso20022.org)
OpenAPI Initiative, OpenAPI Specification (Linux Foundation)
Open Geospatial Consortium (OGC) standards (WMS, WFS, and successors)
European Commission, European Interoperability Framework (EIF) and the Interoperable Europe Act
UK Government, Open Standards Principles and the Technology Code of Practice (GOV.UK)
W3C, RDF, OWL (Web Ontology Language), and semantic-web standards
SNOMED International (SNOMED CT), Regenstrief Institute (LOINC), and WHO (ICD) terminologies
gRPC and Protocol Buffers specifications (Cloud Native Computing Foundation / open source)
NIST and IEEE literature on systems interoperability and conformance testing