क्या मानक होना चाहिए (उदाहरण के लिए, चिकित्सा डेटा)

मूल लेख के लेखक के बारे में संक्षेप में: एडम बोसवर्थ ने बोरलैंड में अपना कैरियर शुरू किया, जहां उन्होंने क्वात्रो स्प्रेडशीट प्रणाली पर काम किया । Microsoft के लिए आगे बढ़ते हुए, उसने विभिन्न नेतृत्व पदों को धारण किया है, जिसमें XML बनाने और बढ़ावा देने में शामिल WebData टीम का नेतृत्व शामिल है। इसके अलावा, उन्होंने एक्सेस और इंटरनेट एक्सप्लोरर 4.0 इंजन पर काम किया, जिसे ट्राइडेंट नाम दिया गया। Microsoft छोड़ने के बाद, एडम क्रॉसगैन के सह-संस्थापकों में से एक बन गया, अधिग्रहण की एक श्रृंखला के बाद, उनका मुख्य उत्पाद WebLogic के लिए Oracle कार्यशाला में बदल गया। 2004-2007 में, Bosworth ने Google पर उत्पाद विकास के उपाध्यक्ष के रूप में कार्य किया, जहां उन्होंने Google डॉक्स पर काम किया और Google स्वास्थ्य के विकास का नेतृत्व किया ( 1 जनवरी 2012 से बंद हो गया , एक बार हब पर इसके बारे में लिखा था )। Google से निकलने के बाद, उन्होंने Keas स्टार्टअप की स्थापना की, जो स्वास्थ्य में सुधार के लिए सामाजिक नेटवर्क और गेम के तत्वों का उपयोग करता है।

इस सप्ताह मुझे विनम्रतापूर्वक मानकों पर एक सरकारी बैठक (1) में एक विशेषज्ञ के रूप में भाग लेने के लिए कहा गया था। इस समय मैं आमतौर पर सोता हूं, लेकिन सही समय पर मैं जाग गया था और नींद पूरी न होने के बावजूद फोन पर बैठ गया था। मुझसे यह क्या करवाया? उन्होंने उन तरीकों पर चर्चा की जिसमें चिकित्सा डेटा को वास्तव में पारदर्शी बनाया जा सकता है। ऐसे डेटा को संयोजित करने के लिए किन मानकों का उपयोग किया जाना चाहिए?

अपने स्वयं के आश्चर्य और कुछ हद तक दर्द के लिए, मैं कई मानकों के विकास में भाग लेने में कामयाब रहा। उनमें से एक का उपयोग स्प्रेडशीट या एक्सेस जैसे डेटाबेस और उपयोगकर्ता अनुप्रयोगों के बीच डेटा का आदान-प्रदान करने के लिए किया गया था। शुरुआत में कुछ कठिनाइयों के बावजूद इसे ODBC कहा गया और बहुत अच्छा प्रदर्शन किया गया। एक और मानक था जिसे अब AJAX कहा जाता है, जो जीमेल जैसे जटिल, इंटरैक्टिव वेब पेज बनाता है। संभवतः सबसे महत्वपूर्ण एक्सएमएल था। ये सभी सफलताएं हैं। असफलताएं थीं। मुझे याद है विशेष रूप से अच्छी तरह से OLE DB जिसके साथ हम ODBC को बदलना / बदलना चाहते थे। सफलता और असफलता के कगार पर संतुलन रखने वालों में से एक XML स्कीमा था । इन सभी प्रयासों के परिणामस्वरूप, मैंने कई सबक सीखे जिन्हें मैं आपके साथ साझा करने का प्रयास करूंगा। वे क्या हैं?

1. मानकों को बेहद सरल और गूंगा बनाएं । विफलता की संभावना कम से कम मानक की जटिलता का वर्ग है। सफल मानक आमतौर पर सरल, केंद्रित और पढ़ने में आसान होते हैं। चिकित्सा की दुनिया में, इसका मतलब है कि हमें पहले उन आंकड़ों पर ध्यान केंद्रित करना होगा जो विशिष्ट रूप से एन्कोड किए जा सकते हैं: जनसांख्यिकीय पैरामीटर, परीक्षण के परिणाम और दवाएं। चिकित्सा के सभी क्षेत्रों से सभी प्रकार के चिकित्सा डेटा को कवर करने की कोशिश करने की आवश्यकता नहीं है। विभिन्न डेटा के लिए अपने भागीदारों के एक्सेस अधिकारों पर ध्यान देने की आवश्यकता नहीं है (नीचे पैराग्राफ 2, 3 और 4 देखें)।

2. एक्सचेंज किए जाने वाले डेटा को मानव-पठनीय और समझने योग्य होना चाहिए। मानकों का भाग्य इंजीनियरों पर निर्भर करता है जो उन्हें कोड में अनुवाद करेंगे। वे ऐसा तभी करेंगे जब वे आसानी से समझ सकें (ऊपर देखें) और मानक का परीक्षण करें। यही कारण है कि पिछले 15 वर्षों में, HTTP, HTML और XML जैसे शाब्दिक मानकों ने विजय प्राप्त की है। डेवलपर्स किसी भी संपादक में प्राप्त / प्रेषित डेटा को देख सकते हैं और सुनिश्चित कर सकते हैं कि सब कुछ वैसा ही हो जैसा कि होना चाहिए। जब टिम बर्नस ली ने पहली बार इंटरनेट के निर्माण के लिए इस दृष्टिकोण को लागू किया, तो अधिकांश "गंभीर" नेटवर्क पेशेवरों ने HTTP में पाठ का उपयोग करने के लिए पागल माना। लेकिन इसने बहुत अच्छा काम किया। जाहिर है, एक्सएमएल के मामले में, यह भी काम किया। इससे हम कुछ निष्कर्ष निकाल सकते हैं। केवल "XML" कहना पर्याप्त नहीं है। औसत इंजीनियर (जो जीवन के लिए मानक लाएगा) को प्रारूप को देखने और समझने में सक्षम होना चाहिए। केवल कंप्यूटर के अनुकूल XML व्याकरणों को देखकर, आप तुरंत अनुमान लगा सकते हैं कि उनका व्यापक रूप से उपयोग नहीं किया जाएगा। कई तथाकथित एक्सएमएल व्याकरण हैं जो एक अमूर्त ज्ञान मॉडल के अंदर एक्सएमएल को छिपाते हैं, जैसे कि आरडीएफ , मेरी राय में उन्हें पढ़ना / समझना बहुत मुश्किल है और व्यापक रूप से उपयोग नहीं किया जाता है। मेरी राय में, Hl7 इससे ग्रस्त है।

3. फोकस्ड मानक सबसे अच्छा काम करते हैं। पड़ोसी क्वार्टरों की यात्राओं के लिए एक भारी ट्रक का निर्माण न करें। मानक अक्सर बहुत असफल हो जाते हैं क्योंकि विभिन्न जटिल लक्ष्यों के साथ समितियां परीक्षण जटिलता (क्लॉज 1 देखें) और स्पष्टता के लिए वर्किंग संस्करण बनाए बिना काम करती हैं (क्लॉज 2 देखें)। वेब की प्रतिभा का एक हिस्सा यह था कि टिम बर्नर्स-ली ने ब्राउज़र (HTML) को प्रदर्शित करने वाले प्रोटोकॉल (HTTP) को सही ढंग से अलग कर दिया था। यह एक लिफाफे से एक पत्र को अलग करने जैसा है। यही आधार है। और जरूरत है। ऐसे मानक जिनमें परतें या स्तर एक बड़ी इकाई में निचोड़ लिए जाते हैं, विफलता की संभावना होती है, क्योंकि खराब इंजीनियरों को हर चीज को समझने की जरूरत होती है, हालांकि वास्तव में उन्हें केवल एक चीज को समझने की आवश्यकता होती है - और इसलिए वे एक बहिष्कार की घोषणा कर रहे हैं। स्वास्थ्य सेवा में, इसका मतलब है कि आपको डेटा एन्कोडिंग के लिए और इसके उपयोग के लिए और सुरक्षा सुनिश्चित करने के लिए एक मानक में नियमों को शामिल करने की आवश्यकता नहीं है। अगर, मुझे एक इंजीनियर के रूप में, केवल रोगी को निर्धारित दवाओं की सूची को सांकेतिक शब्दों में बदलना चाहिए और उसे कहीं भेजना चाहिए जहां उसे वास्तव में ज़रूरत है, तो मुझे कुछ और करने के लिए मजबूर न करें। परिणामस्वरूप XML को एक दवा सूची की तरह दिखना चाहिए। अगर कुछ काम नहीं करता है, तो मैं अपने सहयोगी को कॉल कर सकता हूं और पांच मिनट में पता लगा सकता हूं कि वास्तव में क्या गलत हुआ। ज्यादातर मामलों में, मैं कुछ दिनों में समस्या का समाधान कर सकता हूं, क्योंकि मुझे विनिर्देश का अध्ययन करने की आवश्यकता नहीं होगी क्योंकि टेलीफोन निर्देशिका जितनी मोटी होगी। मुझे "सार डेटा मॉडल" को समझने की आवश्यकता नहीं होगी। मूल XML विनिर्देशन का थोक छोटा था। जानबूझकर। मैंने सुना है कि किसी ने स्वास्थ्य सेवा के लिए सूचना मानकों को आसान बनाने के प्रयासों के बारे में कहा, कि हमें इसे कम करने के बजाय "मानकों के स्तर को ऊपर उठाना चाहिए"। यह हमारे बच्चों को सिखाने की आवश्यकता के समान है कि कैसे उड़ान भरें ताकि वे बाहर जा सकें। सभी सफल मानकों की पहचान चरम सादगी थी, परम जटिलता नहीं।

4. मानकों में सटीक एन्कोडिंग नियम शामिल होने चाहिए। ODBC सही प्रकार से परिभाषित डेटा प्रकार। एक्सएमएल विवरण में सब कुछ संक्षिप्त था, पाठ में एन्कोडिंग वर्णों के सटीक नियमों के अपवाद के साथ, यूनिकोड। यह शायद मानक का सबसे महत्वपूर्ण हिस्सा है, क्योंकि यह एन्कोडिंग सटीकता की गारंटी देता है। स्वास्थ्य सेवा में, इसका मतलब है कि मानक को एन्कोडिंग दवाओं, परीक्षण के परिणामों, जनसांख्यिकीय डेटा, रोगी की स्थिति के डेटा के नियमों को स्पष्ट रूप से परिभाषित करना चाहिए और यह सुनिश्चित करना चाहिए कि सभी रॉयल्टी का भुगतान किए बिना इन नियमों का उपयोग कर सकते हैं। डॉक्टरों के कार्यों के बारे में सभी डेटा के लिए एनपीआई की आवश्यकता के द्वारा सरकार इसे प्रभावित कर सकती है, रोगी की स्थिति के सभी डेटा के लिए SNOMED CT , सभी प्रयोगशाला डेटा के लिए LOINC , सभी दवाओं के लिए विशिष्ट कोडिंग नियम (जो NDC , rxmorm या FDB हो सकते हैं ) और यह सुनिश्चित कर सकते हैं इन नियमों का उपयोग करना हमेशा मुफ्त होगा।

5. हमेशा व्यवहार में कार्यान्वयन होना चाहिए जो वास्तव में मानक का निर्माण करते समय ध्यान में रखा जाता है। कुछ किए बिना, यह समझना बहुत मुश्किल है कि क्या यह काम करेगा और इंजीनियरिंग समझ में आएगा। ODBC बनाते समय, हम में से कई ने इसे प्रक्रिया में लागू किया। स्वास्थ्य सेवा की दुनिया में, हम में से कई ने सीसीआर को इसके निर्माण की प्रक्रिया में विकसित और उपयोग किया, तुरंत समझ में आया कि क्या काम करता है और क्या विशेष रूप से उपयोगी नहीं है, यह चिकित्सा डेटा को एकीकृत करने के लिए एक अच्छा, आसान उपयोग मानक बनाता है। एक साधारण इंजीनियर को कुछ हफ्तों में मानक के कार्यान्वयन को समझने में सक्षम होना चाहिए।

6. अप्रत्याशित परिस्थितियों की संभावना पर विचार करें। नेटवर्क मानक इसका बहुत अच्छा काम करते हैं। यदि HTTP में प्राप्तकर्ता के लिए कुछ समझ से बाहर है, तो वह इसे अनदेखा कर देता है। यह टूटता नहीं है। यदि HTML में ब्राउज़र के लिए कुछ समझ से बाहर है, तो यह इसे अनदेखा करता है। यह टूटता नहीं है। पोस्टेल के कानून को ध्यान में रखें । अप्रत्याशित की अनुमति दें। झूठी सटीकता सफल मानकों का एक कब्रिस्तान है। XML स्कीमा इस संबंध में बहुत खराब है, CCR ज्यादा बेहतर है।

7. मानक खुद को स्वतंत्र बनाएं और इसे कई सरल उदाहरणों के साथ ऑनलाइन प्रकाशित करें। इंजीनियर लोग भी हैं, उनके लिए उदाहरणों से सीखना सबसे आसान है, और यदि मानक ऊपर वर्णित सिद्धांतों का पालन करते हैं, तो उदाहरण स्पष्ट और स्पष्ट होंगे। आप आमतौर पर एक मानक की सफलता की भविष्यवाणी कर सकते हैं यदि इसकी वेबसाइट में स्पष्ट विवरण और सरल, समझने योग्य उदाहरण हैं। HL7 की जटिलता, सामान्यीकरण और अमूर्तता एक साधारण व्यक्ति को पूरी तरह से स्तब्ध कर देती है जो उसकी साइट पर गया था । वह मुझे भी भ्रमित करता है। कोई गलती न करें, इंजीनियर सामान्य लोग हैं जिनके पास बहुत कम समय है। इनमें से अधिकांश के पास डिग्री नहीं है।

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

टिप्पणी:

1. बैठक विवरण का लिंक काम नहीं करता है। जिस ब्लॉग में यह प्रकाशित किया गया था, वह अब नहीं है। लिंक के नाम से, यह माना जा सकता है (अमेरिकी बारीकियों को न जानते हुए) कि यह FACA का ब्लॉग था - 1972 के कानून के आधार पर बनाए गए विशेष विचारशील संगठनों में से एक और सरकारी निकायों और राष्ट्रपति को सार्वजनिक सिफारिशें करने के लिए डिज़ाइन किया गया था।