Google Health API में डेटा मैनेजमेंट

Google Health API में डेटा के साथ काम करने का मुख्य तरीका यह है कि क्लाउड में मौजूद Google Health API के डेटा स्टोर और आपके ऐप्लिकेशन या बैकएंड डेटा स्टोर के बीच डेटा सिंक किया जाए. हालांकि, यह साइकल कई बातों के आधार पर अलग-अलग हो सकती है:

• क्या Google Health API में डेटा लिखा जा रहा है? क्या सिर्फ़ पढ़ने का ऐक्सेस है? या दोनों का इस्तेमाल करना चाहिए?
• क्या आपका डेटास्टोर, ऐप्लिकेशन या डिवाइस पर लोकल है? या अपने क्लाउड में?
• क्या आपको उपयोगकर्ता के ऐप्लिकेशन और पहनने जाने वाले डिवाइस के बीच, Google Health API का डेटा सिंक करना है? डिवाइस कितनी बार सिंक किए जाते हैं?
• आपको किस तरह के डेटा के साथ काम करना है? क्या आपको बुनियादी काउंट चाहिए? मेज़रमेंट की यूनिट क्या हैं? क्या अलग-अलग सैंपल रेट वाली सीरीज़ को एक साथ इस्तेमाल किया जा सकता है?
• क्या आपका ऐप्लिकेशन बैकग्राउंड में काम करते समय डेटा को पढ़ेगा?
• क्या आपको अपने ऐप्लिकेशन को उपयोगकर्ता की अनुमतियां मिलने से पहले रिकॉर्ड किए गए पुराने डेटा का इस्तेमाल करना है?

यह सब एक साथ कैसे काम करता है, यह समझने के लिए Google Health API के डेटा सिंक करने के लाइफ़साइकल पर एक नज़र डालें. इस लाइफ़साइकल के दो वर्शन होते हैं: स्टैंडर्ड (पढ़ने और लिखने की अनुमति) और सिर्फ़ पढ़ने की अनुमति.

सिंक करने की स्टैंडर्ड प्रोसेस का लाइफ़साइकल

पहली इमेज: Google Health API में स्टैंडर्ड सिंक का लाइफ़साइकल

Google Health API के साथ इंटिग्रेट करने का मतलब है कि किसी ऐप्लिकेशन या बैकएंड डेटास्टोर में डेटा कॉपी करना. इस दस्तावेज़ में आसानी से इस्तेमाल करने के लिए, हम इस डेटास्टोर को डेवलपर डेटास्टोर कहेंगे.

यहां "कॉपी करें" की जगह कोई भी गतिविधि की जा सकती है. जैसे, Google Health API से डेटा पढ़ना (डेवलपर के डेटा स्टोर में कॉपी करना) या Google Health API में डेटा लिखना (Google Health API में कॉपी करना). इन कार्रवाइयों को किसी खास क्रम में बार-बार करना, सिंक लाइफ़साइकल कहलाता है.

पहली इमेज में, स्टैंडर्ड सिंक लाइफ़साइकल दिखाया गया है. इसमें पढ़ने और लिखने की कार्रवाइयां शामिल होती हैं. इसमें पहले बताए गए किसी भी फ़ैक्टर पर ध्यान नहीं दिया जाता है.

लिखें

1. डेटा लिखने के लिए नया डेटा तैयार करना — किसी बाहरी डिवाइस या ऐप्लिकेशन से डेटा ट्रांसफ़र करें. साथ ही, डेटा पॉइंट को JSON फ़ॉर्मैट में बदलें, ताकि वे Google Health API के डेटा टाइप के साथ काम कर सकें. ध्यान दें कि फ़िलहाल, Health API में लिखने के लिए, क्लाइंट के असाइन किए गए कस्टम आईडी इस्तेमाल नहीं किए जा सकते. इस तरह के आईडी, POST में दिए जा सकते हैं. हालांकि, इन्हें अनदेखा कर दिया जाता है.
2. रिकॉर्ड अपडेट करना या नए रिकॉर्ड जोड़ना — REST एंडपॉइंट का इस्तेमाल करके, Google Health API को डेटा पॉइंट सबमिट करें. रिकॉर्ड बनाने के लिए POST का इस्तेमाल करें. साथ ही, मौजूदा रिकॉर्ड डालने और उन्हें अपडेट करने के लिए PATCH का इस्तेमाल करें. PATCH ऑपरेशन के लिए ज़रूरी आईडी, POST ऑपरेशन (पिछले साइकल का अगला चरण) से मिले होंगे.
3. सर्वर से मिले संसाधन आईडी प्रोसेस करना — सर्वर से जनरेट किए गए आईडी का इस्तेमाल करते समय, डेवलपर के डेटास्टोर में सर्वर से मिले संसाधन name या आईडी को एक्सट्रैक्ट करें और सेव करें. इससे आने वाले समय में अपडेट (PATCH) या मिटाने (DELETE) की सुविधा चालू की जा सकेगी. दोनों तरह के आईडी के बारे में ज़्यादा जानने के लिए, पहचान करने की रणनीतियां देखें.

पढ़ें

1. रिकॉर्ड पढ़ना — REST एंडपॉइंट (GET के साथ filter क्वेरी पैरामीटर और pageToken पेज पर बांटना या rollUp और dailyRollUp जैसे एग्रीगेशन एंडपॉइंट) का इस्तेमाल करके, Google Health API से नया डेटा फ़ेच करें और मौजूदा डेटा में हुए बदलावों को फ़ेच करें. इसके अलावा, Webhook सदस्यताएं (projects.subscribers) का इस्तेमाल करके, रीयल-टाइम सूचनाएं पाएं. सूचना से सिर्फ़ यह पता चलता है कि नया डेटा उपलब्ध है. इससे यह पता नहीं चलता कि असल डेटा क्या है.
2. डेवलपर के डेटास्टोर का मिलान करें — नए और अपडेट किए गए डेटा का मिलान, डेवलपर के डेटास्टोर से करें. सिंक करने के दौरान, कनेक्ट किए गए डिवाइसों से एक जैसे इंटरवल मिल सकते हैं. Google Health API इन समस्याओं को कैसे हल करता है, यह जानने के लिए इंटरवल के टाइमस्टैंप और कनेक्ट किए गए डिवाइस को सिंक करना लेख पढ़ें.

इसके बाद, यह साइकल बाहरी डिवाइसों या ऐप्लिकेशन की खास ज़रूरतों के हिसाब से, तय समय पर दोहराई जाती है. आम तौर पर, हम आपके डेटास्टोर और Google Health API के बीच डेटा सिंक करने के लिए, इस क्रम का सुझाव देते हैं.

पहचान करने की रणनीतियां

अगर आपको Google Health API में डेटा सेव करना है, तो Google Health API के साथ इंटिग्रेशन बनाने से पहले, आपको डेटा पॉइंट (डेटा की बुनियादी इकाई) बनाते समय, संसाधन की पहचान करने की रणनीति चुननी होगी.

फ़िलहाल, Health API में लिखने के लिए क्लाइंट के असाइन किए गए आईडी इस्तेमाल नहीं किए जा सकते. इस तरह के आईडी, POST में दिए जा सकते हैं. हालांकि, इन्हें अनदेखा कर दिया जाता है. इस विकल्प के बारे में जानकारी देने के लिए, यहां ब्यौरा दिया गया है.

1. सर्वर से जनरेट किए गए आईडी (डिफ़ॉल्ट विकल्प): क्लाइंट, आईडी के बिना डेटा सबमिट करता है. इसके बाद, Google Health API का बैकएंड, यूनीक सिस्टम आइडेंटिफ़ायर जनरेट करता है और उसे वापस भेजता है.
2. क्लाइंट की ओर से असाइन किए गए कस्टम आईडी (हर AIP-133 के लिए, फ़िलहाल उपलब्ध नहीं है): क्लाइंट ऐप्लिकेशन, यूनीक आइडेंटिफ़ायर जनरेट करता है. उदाहरण के लिए, यूयूआईडी या लोकल डेटाबेस प्राइमरी कुंजी. इसके बाद, इसे संसाधन पाथ में उपलब्ध कराता है.

यहां दी गई टेबल में, दोनों आइडेंटिफ़िकेशन रणनीतियों की तुलना की गई है. इससे आपको अपने इंटिग्रेशन के लिए सही तरीका चुनने में मदद मिलेगी:

सुविधा	सर्वर से जनरेट किए गए आईडी	क्लाइंट की ओर से असाइन किए गए कस्टम आईडी
आईडी जनरेट करना	सर्वर, POST को लागू करने के दौरान, सिस्टम आईडी को अपने-आप जनरेट करता है.	क्लाइंट, राइट ऑपरेशन से पहले स्थानीय तौर पर स्टेबल आईडी जनरेट करता है (UUID v4 / इंटरनल पीके).
संसाधन का पाथ	.../dataPoints/{server_id} (जवाब में मिला)	.../dataPoints/{custom_id}
Post-Write Local Step	ज़रूरी है. आने वाले समय में अपडेट/मिटाने की सुविधा चालू करने के लिए, लौटाए गए server_id को लोकल डीबी में सेव करना ज़रूरी है.	कोई नहीं. ऐप्लिकेशन के पास पहले से ही आईडी का मालिकाना हक है.
आईडी मैपिंग टेबल	ज़रूरी है. क्लाइंट को दोनों तरह की मैपिंग (local_id ↔ server_id) बनाए रखनी होगी.	ज़रूरी नहीं है. क्लाइंट, अपनी प्राइमरी कुंजी का सीधे तौर पर इस्तेमाल करता है.
फिर से कोशिश करने का तरीका (कमज़ोर नेटवर्क)	डुप्लीकेट होने का जोखिम. टाइम आउट हो चुके POST को फिर से आज़माने पर, एक डुप्लीकेट रिकॉर्ड बन जाता है. इसमें नया सर्वर आईडी होता है.	सुरक्षित और आइडेमपोटेंट. एक ही custom_id के साथ POST को फिर से आज़माने पर, डुप्लीकेट नहीं बनता (409 ALREADY_EXISTS दिखाता है).
ऑफ़लाइन सिंक करने की सुविधा	सीमित है. इनका रेफ़रंस देने से पहले, सर्वर के जवाब का इंतज़ार करना होगा, ताकि आधिकारिक संसाधन आईडी मिल सकें.	पूरी. ऑफ़लाइन होने पर भी, स्टेबल आईडी का इस्तेमाल करके इकाइयां बनाई और उनमें बदलाव किया जा सकता है. इसके बाद, इंटरनेट से कनेक्ट होने पर उन्हें आसानी से सिंक किया जा सकता है.
फ़ॉर्मैट से जुड़ी पाबंदियां	इसे पूरी तरह से सर्वर मैनेज करता है.	इसमें ^[a-z0-9-]{4,63}$ (4–63 छोटे अक्षर, अक्षर-अंक, और हाइफ़न) होने चाहिए.
इसे कब चुनें	अगर आपको सर्वर से जनरेट होने वाले आईडी इस्तेमाल करने हैं, तो: आपका ऐप्लिकेशन सिर्फ़ लिखने / जोड़ने की अनुमति देता है.उदाहरण के लिए, टेलीमेट्री या कदमों की संख्या भेजना. इस डेटा को बाद में कभी अपडेट या मिटाया नहीं जाता. आपका ऐप्लिकेशन, अलग-अलग डेटा पॉइंट का लोकल परसिस्टेंट डेटाबेस नहीं रखता है. आपको स्ट्रिंग की पुष्टि करने से जुड़ी पाबंदियों (जैसे कि 4-63 वर्ण) को मैनेज किए बिना, आसान तरीके से काम करना है.	कस्टम आईडी तब चुनें, जब: आपके पास दोनों तरह से सिंक करने वाला एक ऐप्लिकेशन है. यह ऐप्लिकेशन, सभी डिवाइसों पर मौजूद स्वास्थ्य से जुड़े रिकॉर्ड को पढ़ता है, उनमें बदलाव करता है, और उन्हें अपडेट करता है. आपके ऐप्लिकेशन में एक लोकल डेटाबेस (जैसे, Room या SQLite) है, जिसमें लोकल प्राइमरी कुंजियों वाले रिकॉर्ड सेव किए जाते हैं. आपके उपयोगकर्ता, ऑफ़लाइन या बीच-बीच में मोबाइल कनेक्शन के ज़रिए डेटा रिकॉर्ड करते हैं. ऐसे में, सुरक्षित तरीके से फिर से कोशिश करना ज़रूरी होता है. आपको अपने बैकएंड डेटाबेस और एपीआई के बीच आईडी मैपिंग टेबल को हटाना है.

रीड-ओनली सिंक का लाइफ़साइकल

दूसरी इमेज: Google Health API में रीड-ओनली सिंक का लाइफ़साइकल

अगर कोई ऐप्लिकेशन सिर्फ़ Google Health API से डेटा पढ़ना चाहता है, तो उसे डेटा को अपने डेवलपर डेटास्टोर में कॉपी करना होगा. साथ ही, लाइफ़साइकल के रिकॉन्सिलिएशन वाले हिस्से को मैनेज करना होगा.

पढ़ें सेक्शन में बताए गए टास्क यहां भी लागू होते हैं.

दूसरी इमेज में, रीड-ओनली लाइफ़साइकल के बारे में बताया गया है.

इंटरवल के टाइमस्टैंप और कनेक्ट किए गए डिवाइसों के साथ सिंक करने की सुविधा

इंटरवल डेटा, किसी समयावधि में इकट्ठा किए गए मेज़रमेंट को दिखाता है. जैसे, कदमों की संख्या, धड़कन की दर या कसरत के सेशन. इसके उलट, किसी समय की गई मेज़रमेंट में, मैन्युअल तरीके से की गई एंट्री शामिल होती हैं. जैसे, फ़ूड लॉग या स्केल रीडिंग. इंटरवल का डेटा आम तौर पर, कनेक्ट किए गए डिवाइसों को सिंक करने से मिलता है. जैसे, स्मार्टवॉच और फ़िटनेस ट्रैकर.

इंटरवल टाइमस्टैंप (REST JSON पेलोड में startTime और endTime या फ़िल्टर एक्सप्रेशन और gRPC में start_time और end_time) की मदद से, इंटरवल डेटा के साथ काम करते समय खास व्यवहारों को लागू किया जा सकता है. इस सेक्शन में बताया गया है कि समयसीमाएं एक-दूसरे से क्यों ओवरलैप करती हैं. साथ ही, इसमें list और reconcile एंडपॉइंट की तुलना की गई है.

कनेक्ट किए गए डिवाइसों से मिले, एक-दूसरे से मिलते-जुलते अंतराल वाले डेटा को मर्ज करना

Fitbit ट्रैकर और Google Pixel Watch जैसे कनेक्ट किए गए डिवाइस, पहने जाने पर लगातार बायोमेट्रिक डेटा इकट्ठा करते हैं. कोई डिवाइस, Google Health के साथ डेटा पॉइंट सिंक करने के बाद, मौजूदा रिकॉर्ड में बदलाव नहीं करता. उनके सेव किए गए इंटरवल के टाइमस्टैंप में कोई बदलाव नहीं होता.

हालांकि, सिंक करने के बाद के साइकल से पहले, डिवाइस पर मौजूद एल्गोरिदम अक्सर सेंसर से मिले डेटा की फिर से व्याख्या करते हैं. डिवाइस, पिछले कुछ घंटों में इकट्ठा की गई रीडिंग को फिर से बकेट करता है. डिवाइस के फिर से सिंक होने पर, नए डेटा पॉइंट अपलोड हो जाते हैं. इनकी शुरुआत और खत्म होने की सीमाएं, पहले से सेव किए गए इंटरवल से ओवरलैप हो सकती हैं.

उदाहरण के लिए, स्मार्टवॉच पहनने वाले किसी ऐसे उपयोगकर्ता के बारे में सोचें जिसकी गतिविधि से जुड़ा डेटा, लगातार दो बैच में सिंक किया गया है:

1. पहली बार सिंक करने के दौरान, डिवाइस 10:00:00Z से 10:14:59Z तक का डेटा पॉइंट अपलोड करता है.
2. उपयोगकर्ता के डिवाइस पर फिर से हिसाब लगाने के बाद, दूसरा सिंक 10:14:00Z से 10:28:59Z तक के डेटा पॉइंट को अपलोड करता है.

दोनों रिकॉर्ड, Google Health के बैकएंड में अलग-अलग सेव किए जाते हैं. इस वजह से, दोनों डेटा पॉइंट में 10:14:00Z से 10:14:59Z तक का इंटरवल शामिल होता है. इससे रॉ रिकॉर्ड के लिए क्वेरी करते समय, 59 सेकंड का ओवरलैप होता है.

सूची और मिलान करने वाले एंडपॉइंट की तुलना करना

list या reconcile एंडपॉइंट का इस्तेमाल करके, एक-दूसरे से ओवरलैप होने वाले इन इंटरवल को मैनेज किया जा सकता है. अपने ऐप्लिकेशन की ज़रूरतों के हिसाब से एंडपॉइंट चुनें:

सुविधा	list एंडपॉइंट	reconcile एंडपॉइंट
एचटीटीपी मेथड	GET https://health.googleapis.com/v4/users/me/dataTypes/dataType/dataPoints	GET https://health.googleapis.com/v4/users/me/dataTypes/dataType/dataPoints:reconcile
ओवरलैप होने का तरीका	यह फ़ंक्शन, सेव किए गए सभी रिकॉर्ड को अपलोड किए गए डेटा के तौर पर दिखाता है. इसमें डुप्लीकेट रिकॉर्ड शामिल नहीं होते. इंटरवल ओवरलैप होने पर, दोनों रिकॉर्ड दिखाए जाते हैं.	यह कुकी, अलग-अलग डिवाइसों और सिंक सेशन में मौजूद एक जैसे रिकॉर्ड के बीच के अंतर को मिटाती है. साथ ही, उन्हें एक ही स्ट्रीम में सिंक करती है.
फ़ायदे	यह हर डिवाइस और सिंक बैच से अपलोड किए गए हर रिकॉर्ड का पूरा और बिना बदलाव वाला ऑडिट ट्रेल उपलब्ध कराता है.	यह टाइमलाइन रेंडरिंग और अवधि की गणना को आसान बनाता है. ऐसा इसलिए, क्योंकि यह ओवरलैप होने वाले इंटरवल और मल्टी-डिवाइस के बीच होने वाले टकराव को अपने-आप हैंडल करता है.
नुकसान	आपके ऐप्लिकेशन की यह ज़िम्मेदारी है कि वह एक-दूसरे से ओवरलैप होने वाले इंटरवल, एक से ज़्यादा डिवाइसों के बीच होने वाले टकराव, और डिवाइस को कलाई से हटाने के समय का पता लगाए और उन्हें ठीक करे.	जवाब में, ओवरलैप होने वाले सबऑर्डिनेट रिकॉर्ड शामिल नहीं किए जाते. इसलिए, डिवाइस के सिंक किए गए अलग-अलग बैच की ऑडिट अलग से नहीं की जा सकती.

reconcile एंडपॉइंट को यूज़र इंटरफ़ेस (यूआई) बनाने, गतिविधि की टाइमलाइन रेंडर करने, और बिना ओवरलैप वाली अवधि के कुल समय का हिसाब लगाने के लिए डिज़ाइन किया गया है. यह फिर से बकेट किए गए सिंक सेशन से, टकराव वाले इंटरवल को ठीक करता है. यह एक साथ कई डिवाइसों पर लॉग की गई गतिविधि का मिलान भी करता है. जैसे, घड़ी और फ़ोन.

रिकॉन्सिलिएशन, आर्टिफ़िशियल टाइम यूनियन को सिंथेसाइज़ करने के बजाय, आधिकारिक रिकॉर्ड चुनकर टकराव वाले सेशन को ठीक करता है. उदाहरण के लिए, यह 11:00:00Z से 11:30:00Z और 11:20:00Z से 11:50:00Z को 11:00:00Z से 11:50:00Z में नहीं बदलता. मिलान किए गए जवाब में, सबसे सटीक डेटा पॉइंट को उसके मूल रिकॉर्ड किए गए इंटरवल के साथ दिखाया जाता है. इससे उस सेशन की मेज़र की गई टेलीमेट्री और मेट्रिक की विश्वसनीयता बनी रहती है.

तीसरी इमेज में दिखाया गया है कि reconcile एंडपॉइंट, ओवरलैप होने वाले सेशन को कैसे मैनेज करता है. यह आर्टिफ़िशियल टाइम यूनियन बनाने के बजाय, आधिकारिक रिकॉर्ड चुनता है.

तीसरी इमेज: सेशन रीकंसिलिएशन और आर्टिफ़िशियल टाइम यूनियन मर्ज के बीच अंतर

एंडपॉइंट गाइड में, अनुरोध और जवाब के उदाहरण दिए गए हैं. reconcile आउटपुट के साथ रॉ list रिकॉर्ड की तुलना करने के लिए, इंटरवल डेटा का मेल मिलाया गया व्यू पाएं लेख पढ़ें.

list एंडपॉइंट को डिवाइस की परफ़ॉर्मेंस की जांच करने और डेटा ऑडिट के लिए डिज़ाइन किया गया है. इसका इस्तेमाल तब करें, जब आपके वर्कफ़्लो में हर डिवाइस से अपलोड किए गए, बिना बदलाव वाले रिकॉर्ड की जांच करना ज़रूरी हो. list के साथ क्वेरी करते समय, आपके क्लाइंट लॉजिक को रॉ डेटा में इंटरवल के किसी भी ओवरलैप को मैनेज करना होगा.

टाइमस्टैंप में बदलाव करने की सुविधा और मालिक के अपडेट

कनेक्ट किए गए डिवाइस, सामान्य सिंक साइकल के दौरान सेव किए गए टाइमस्टैंप में बदलाव नहीं करते. हालांकि, इंटरवल टाइमस्टैंप (REST JSON पेलोड में startTime और endTime या फ़िल्टर एक्सप्रेशन और gRPC में start_time और end_time) सभी डेटा सोर्स के लिए एक जैसे नहीं होते. किसी रिकॉर्ड के फ़ील्ड में बदलाव सिर्फ़ उसका ओरिजनल क्रिएटर या मालिक कर सकता है. अन्य ऐप्लिकेशन, उन डेटा पॉइंट में बदलाव नहीं कर सकते जिन्हें उन्होंने नहीं बनाया है.

मालिक का ऐप्लिकेशन, अपने मौजूदा रिकॉर्ड अपडेट करने के लिए patch एंडपॉइंट का इस्तेमाल कर सकता है. इसमें शुरू या खत्म होने के टाइमस्टैंप में बदलाव करना शामिल है. इससे सर्वर पर यूटीसी (startTime और endTime) और सिविल टाइम (civilStartTime और civilEndTime), दोनों फ़ील्ड अपडेट हो जाते हैं. PATCH का इस्तेमाल करके टाइमस्टैंप अपडेट करने का उदाहरण देखने के लिए, एंडपॉइंट गाइड में मौजूदा डेटा के लिए अपडेट इंटरवल टाइमस्टैंप देखें.

इसी तरह, Health Connect या पार्टनर ऐप्लिकेशन जैसे बाहरी प्लैटफ़ॉर्म से सिंक किए गए डेटा पॉइंट, ओरिजनल सोर्स से अपडेट पाते हैं. अगर Health Connect को सिंक किए गए किसी रिकॉर्ड के लिए, तीसरे पक्ष के मूल ऐप्लिकेशन से कोई अपडेट मिलता है, तो वे बदलाव लागू हो जाते हैं और मौजूदा रिकॉर्ड बदल जाता है.

चेतावनी: कभी भी यह न मान लें कि किसी डेटा पॉइंट के इंटरवल टाइमस्टैंप हमेशा के लिए तय होते हैं. डेटा पॉइंट को स्थानीय तौर पर कैश मेमोरी में सेव करते समय, पक्का करें कि आपकी सिंक्रनाइज़ेशन पाइपलाइन, मौजूदा रिकॉर्ड और उनके इंटरवल के अपडेट को मैनेज करती हो.