গুগল হেলথ এপিআই-তে ডেটা নিয়ে কাজ করার মূল ভিত্তি হলো ক্লাউডে থাকা গুগল হেলথ এপিআই ডেটাস্টোর এবং আপনার নিজের অ্যাপ বা ব্যাকএন্ড ডেটাস্টোরের মধ্যে ডেটা সিঙ্ক করার একটি চক্র। তবে, বিভিন্ন কারণের উপর নির্ভর করে এই চক্রটি ভিন্ন রূপ নিতে পারে:
- আপনি কি গুগল হেলথ এপিআই-তে ডেটা লিখছেন? শুধু পড়ছেন? নাকি দুটোই করছেন?
- আপনার ডেটাস্টোরটি কি অ্যাপ বা ডিভাইসে স্থানীয়ভাবে অবস্থিত? নাকি আপনার নিজস্ব ক্লাউডে?
- ব্যবহারকারীর অ্যাপ এবং পরিধানযোগ্য ডিভাইসের মধ্যে কি গুগল হেলথ এপিআই ডেটা সিঙ্ক করার প্রয়োজন আছে? আপনি কত ঘন ঘন ডিভাইসগুলো সিঙ্ক করেন?
- আপনি কী ধরনের ডেটা নিয়ে কাজ করছেন? সাধারণ গণনা? পরিমাপের একক? নাকি বিভিন্ন স্যাম্পলিং হারযুক্ত সিরিজ?
- আপনার অ্যাপটি ব্যাকগ্রাউন্ডে থাকা অবস্থায় আপনি কি ডেটা পড়ার পরিকল্পনা করছেন?
- আপনার অ্যাপ ব্যবহারকারীর অনুমতি পাওয়ার আগে রেকর্ড করা ঐতিহাসিক ডেটা নিয়ে কাজ করার পরিকল্পনা কি আপনার আছে?
এই সবকিছু কীভাবে একসাথে কাজ করে তা বোঝার জন্য, গুগল হেলথ এপিআই সিঙ্ক লাইফসাইকেলটি দেখুন। এই লাইফসাইকেলের দুটি সংস্করণ রয়েছে: স্ট্যান্ডার্ড (পড়া এবং লেখার ক্ষমতা) এবং রিড-অনলি।
স্ট্যান্ডার্ড সিঙ্ক জীবনচক্র
গুগল হেলথ এপিআই-এর সাথে ইন্টিগ্রেট করার অর্থ হলো কোনো অ্যাপ বা ব্যাকএন্ড ডেটাস্টোরে ডেটা কপি করা। এই ডকুমেন্টেশনে ব্যবহারের সুবিধার জন্য, আমরা এই ডেটাস্টোরটিকে ‘ডেভেলপার ডেটাস্টোর’ বলব।
এখানে "কপি" বলতে যেকোনো স্বতন্ত্র কার্যকলাপকে বোঝানো হতে পারে, যেমন গুগল হেলথ এপিআই থেকে ডেটা পড়া (ডেভেলপার ডেটাস্টোরে কপি করা) অথবা গুগল হেলথ এপিআই-তে ডেটা লেখা (গুগল হেলথ এপিআই-তে কপি করা)। একটি নির্দিষ্ট ক্রমে এই কাজগুলো বারবার করাই হলো সিঙ্ক লাইফসাইকেল।
চিত্র ১-এ আদর্শ সিঙ্ক জীবনচক্রটি দেখানো হয়েছে, যেখানে পূর্বে উল্লিখিত কোনো বিষয় বিবেচনা না করেই পঠন ও লিখন কার্যক্রম অন্তর্ভুক্ত রয়েছে।
লিখুন
- লেখার জন্য নতুন ডেটা প্রস্তুত করুন — একটি বাহ্যিক ডিভাইস বা অ্যাপ থেকে ডেটা স্থানান্তর করুন এবং ডেটা পয়েন্টগুলিকে Google Health API ডেটা টাইপের সাথে সামঞ্জস্যপূর্ণ JSON উপস্থাপনায় ফরম্যাট করুন। উল্লেখ্য যে, এই মুহূর্তে Health API-তে লেখার জন্য ক্লায়েন্ট-নির্ধারিত কাস্টম আইডি সমর্থিত নয়। এই ধরনের আইডি একটি
POSTমাধ্যমে প্রদান করা যেতে পারে, কিন্তু সেগুলি উপেক্ষা করা হয়। - রেকর্ড আপসার্ট করুন — REST এন্ডপয়েন্ট ব্যবহার করে Google Health API-তে ডেটা পয়েন্ট জমা দিন। রেকর্ড তৈরি করার জন্য
POSTএবং বিদ্যমান রেকর্ড ইনসার্ট ও আপডেট করার জন্যPATCHব্যবহার করুন।PATCHঅপারেশনের জন্য প্রয়োজনীয় আইডিগুলো পূর্ববর্তী কোনোPOSTঅপারেশন (পূর্ববর্তী চক্রের পরবর্তী ধাপ) থেকে আসবে। - ফেরত আসা রিসোর্স আইডিগুলো প্রসেস করুন — সার্ভার-জেনারেটেড আইডি ব্যবহার করার সময়, ভবিষ্যতের আপডেট (
PATCH) বা ডিলিট (DELETE) সক্ষম করার জন্য সার্ভার থেকে ফেরত আসা রিসোর্সেরnameবা আইডি আপনার ডেভেলপার ডেটাস্টোরে এক্সট্র্যাক্ট এবং পারসিস্ট করুন। এই দুই প্রকার সম্পর্কে আরও তথ্যের জন্য আইডেন্টিফিকেশন স্ট্র্যাটেজিস দেখুন।
পড়ুন
- রেকর্ড পড়ুন — REST এন্ডপয়েন্ট (
filterকোয়েরি প্যারামিটার এবংpageTokenপেজিনেশন সহGET, অথবাrollUpএবংdailyRollUpমতো অ্যাগ্রিগেশন এন্ডপয়েন্ট) ব্যবহার করে Google Health API থেকে নতুন ডেটা এবং বিদ্যমান ডেটার পরিবর্তনগুলি সংগ্রহ করুন, অথবা ওয়েবহুক সাবস্ক্রিপশন (projects.subscribers) ব্যবহার করে রিয়েল-টাইম নোটিফিকেশন পান। একটি নোটিফিকেশন শুধুমাত্র নতুন ডেটা উপলব্ধ হওয়ার বিষয়টি জানায়, কিন্তু প্রকৃত ডেটা কী তা জানায় না। - ডেভেলপার ডেটাস্টোর সমন্বয় করুন — আপনার ডেভেলপার ডেটাস্টোরে নতুন এবং আপডেট করা ডেটা সমন্বয় করুন। সিঙ্ক করার সময় সংযুক্ত ডিভাইসগুলো ওভারল্যাপিং ইন্টারভ্যাল তৈরি করতে পারে। গুগল হেলথ এপিআই কীভাবে এগুলোর সমাধান করে তা জানতে, ‘ইন্টারভ্যাল টাইমস্ট্যাম্প এবং সংযুক্ত ডিভাইস সিঙ্কিং’ দেখুন।
এরপর বাহ্যিক ডিভাইস বা অ্যাপের নির্দিষ্ট প্রয়োজন অনুযায়ী এই চক্রটি উপযুক্ত বিরতিতে পুনরাবৃত্ত হয়। আপনার নিজস্ব ডেটাস্টোর এবং গুগল হেলথ এপিআই-এর মধ্যে ডেটা সিঙ্ক করার জন্য আমরা সাধারণত এই ক্রমটিই সুপারিশ করি।
শনাক্তকরণ কৌশল
আপনি যদি গুগল হেলথ এপিআই-তে ডেটা লিখতে চান, তবে গুগল হেলথ এপিআই-এর সাথে আপনার ইন্টিগ্রেশন তৈরি করার আগে, ডেটা পয়েন্ট (ডেটার মৌলিক একক) তৈরি করার সময় আপনাকে অবশ্যই একটি রিসোর্স আইডেন্টিফিকেশন স্ট্র্যাটেজি বেছে নিতে হবে।
বর্তমানে হেলথ এপিআই-তে রাইট (write) এর জন্য ক্লায়েন্ট-নির্ধারিত আইডি সমর্থিত নয়। এই ধরনের আইডি একটি POST মাধ্যমে প্রদান করা যেতে পারে, কিন্তু সেগুলি উপেক্ষা করা হয়। এই বিকল্পটির বিশদ বিবরণ শুধুমাত্র তথ্যের জন্য এখানে দেওয়া হয়েছে।
- সার্ভার-জেনারেটেড আইডি (ডিফল্ট অপশন) : ক্লায়েন্ট আইডি ছাড়া ডেটা জমা দেয় এবং গুগল হেলথ এপিআই ব্যাকএন্ড একটি অনন্য সিস্টেম আইডেন্টিফায়ার তৈরি করে ফেরত দেয়।
- ক্লায়েন্ট-নির্ধারিত কাস্টম আইডি ( AIP-133 অনুযায়ী, এখনও সমর্থিত নয়) : ক্লায়েন্ট অ্যাপ একটি অনন্য শনাক্তকারী (যেমন, একটি UUID বা স্থানীয় ডেটাবেস প্রাইমারি কী) তৈরি করে এবং রিসোর্স তৈরির সময় পাথে তা সরবরাহ করে।
আপনার ইন্টিগ্রেশনের জন্য সঠিক পদ্ধতিটি বেছে নিতে সাহায্য করার উদ্দেশ্যে, নিম্নলিখিত সারণিতে উভয় শনাক্তকরণ কৌশলের তুলনা করা হয়েছে:
| বৈশিষ্ট্য | সার্ভার-উত্পাদিত আইডি | ক্লায়েন্ট-নির্ধারিত কাস্টম আইডি |
|---|---|---|
| আইডি জেনারেশন | POST নির্বাহের সময় সার্ভার একটি র্যান্ডম সিস্টেম আইডি তৈরি করে। | ক্লায়েন্ট লেখার আগে স্থানীয়ভাবে একটি স্থিতিশীল আইডি (UUID v4 / অভ্যন্তরীণ PK) তৈরি করে। |
| রিসোর্স পাথ | .../dataPoints/{server_id} (প্রতিক্রিয়ায় ফেরত দেওয়া হয়েছে) | .../dataPoints/{custom_id} |
| পোস্ট-রাইট লোকাল স্টেপ | আবশ্যক। ভবিষ্যতে আপডেট/ডিলিট করার জন্য প্রাপ্ত server_id অবশ্যই স্থানীয় ডেটাবেসে সংরক্ষণ করতে হবে। | কোনোটিই নয়। অ্যাপটির কাছে আইডিটি আগে থেকেই রয়েছে। |
| আইডি ম্যাপিং টেবিল | আবশ্যক। ক্লায়েন্টকে অবশ্যই একটি দ্বি-মুখী ম্যাপিং ( local_id ↔ server_id ) বজায় রাখতে হবে। | প্রয়োজন নেই। ক্লায়েন্ট সরাসরি তার নিজস্ব প্রাইমারি কী ব্যবহার করে। |
| পুনরায় চেষ্টার আচরণ (দুর্বল নেটওয়ার্ক) | ডুপ্লিকেট হওয়ার ঝুঁকি। টাইম-আউট হয়ে যাওয়া একটি POST অনুরোধ পুনরায় চেষ্টা করলে একটি নতুন সার্ভার আইডি সহ একটি ডুপ্লিকেট রেকর্ড তৈরি হয়। | নিরাপদ ও আইডম্পোটেন্ট। একই custom_id দিয়ে পুনরায় POST চেষ্টা করলে ডুপ্লিকেট তৈরি হওয়া প্রতিরোধ করা যায় ( 409 ALREADY_EXISTS রিটার্ন করে)। |
| অফলাইন সিঙ্ক সমর্থন | সীমিত। অফিসিয়াল রিসোর্স আইডিগুলো ব্যবহার করার আগে অবশ্যই সার্ভারের প্রতিক্রিয়ার জন্য অপেক্ষা করতে হবে। | সম্পূর্ণ। সত্তাগুলোকে স্থিতিশীল আইডি দিয়ে অফলাইনে তৈরি ও পরিবর্তন করা যায়, এবং পুনরায় সংযোগ স্থাপন করলে সেগুলো নির্বিঘ্নে সিঙ্ক হয়ে যায়। |
| বিন্যাস সীমাবদ্ধতা | সম্পূর্ণভাবে সার্ভার দ্বারা পরিচালিত। | অবশ্যই ^[a-z0-9-]{4,63}$ (৪-৬৩টি ছোট হাতের অক্ষর, সংখ্যা ও হাইফেন) অনুসরণ করতে হবে। |
| কখন বেছে নিতে হবে | সার্ভার-জেনারেটেড আইডি বেছে নিন যদি:
| নিম্নলিখিত ক্ষেত্রে কাস্টম আইডি বেছে নিন:
|
রিড-অনলি সিঙ্ক জীবনচক্র
যে অ্যাপ শুধুমাত্র গুগল হেলথ এপিআই থেকে ডেটা পড়তে চায়, তাকে অবশ্যই ডেটাগুলো তাদের ডেভেলপার ডেটাস্টোরে কপি করতে হবে এবং লাইফসাইকেলের রিকনসিলিয়েশন অংশটি পরিচালনা করতে হবে।
'পড়া' অংশে আলোচিত কাজগুলো এখানেও প্রযোজ্য।
চিত্র ২-এ পঠন-যোগ্য জীবনচক্রটি দেখানো হয়েছে।
ব্যবধানের টাইমস্ট্যাম্প এবং সংযুক্ত ডিভাইস সিঙ্কিং
ইন্টারভাল ডেটা বলতে একটি নির্দিষ্ট সময় ধরে সংগৃহীত পরিমাপকে বোঝায়, যেমন পদক্ষেপ, হৃদস্পন্দন বা ব্যায়ামের সেশন। এর বিপরীতে, নির্দিষ্ট সময়ের পরিমাপের মধ্যে হাতে লেখা তথ্য অন্তর্ভুক্ত থাকে, যেমন খাবারের তালিকা বা ওজন মাপার যন্ত্রের রিডিং। ইন্টারভাল ডেটা সাধারণত স্মার্টওয়াচ এবং ফিটনেস ট্র্যাকারের মতো সংযুক্ত ডিভাইসগুলো সিঙ্ক করার মাধ্যমে তৈরি হয়।
ইন্টারভাল ডেটা নিয়ে কাজ করার সময় ইন্টারভাল টাইমস্ট্যাম্প ( startTime এবং endTime ) কিছু স্বতন্ত্র আচরণ প্রদর্শন করে। এই অংশে ব্যাখ্যা করা হয়েছে কেন ওভারল্যাপিং ইন্টারভাল ঘটে এবং list তুলনা করে প্রান্তবিন্দুগুলোর মধ্যে reconcile ।
সংযুক্ত ডিভাইসগুলি থেকে ওভারল্যাপিং ব্যবধান
ফিটবিট ট্র্যাকার এবং গুগল পিক্সেল ওয়াচের মতো সংযুক্ত ডিভাইসগুলো পরিধান করা অবস্থায় ক্রমাগত উচ্চ-ফ্রিকোয়েন্সির বায়োমেট্রিক রিডিং সংগ্রহ করে। কোনো ডিভাইস গুগল হেলথ-এ ডেটা পয়েন্ট সিঙ্ক করার পর, এটি পূর্ববর্তী সেই রেকর্ডগুলোকে পরিবর্তন করে না। সেগুলোর সংরক্ষিত ইন্টারভ্যাল টাইমস্ট্যাম্প অপরিবর্তিত থাকে।
তবে, পরবর্তী সিঙ্ক চক্রের আগে, ডিভাইসের অ্যালগরিদমগুলো প্রায়শই সেন্সরের মূল ডেটা পুনরায় ব্যাখ্যা করে। ডিভাইসটি বিগত কয়েক ঘণ্টার সংগৃহীত রিডিংগুলোকে নতুন করে বিন্যস্ত করে। ডিভাইসটি যখন আবার সিঙ্ক করে, তখন এটি নতুন ডেটা পয়েন্ট আপলোড করে। এগুলোর শুরু এবং শেষের সীমানা পূর্বে সংরক্ষিত সময়কালের সাথে মিলে যেতে পারে।
উদাহরণস্বরূপ, এমন একজন ব্যবহারকারীর কথা ভাবুন যিনি একটি স্মার্টওয়াচ পরেন এবং যার কার্যকলাপের ডেটা পরপর দুটি ব্যাচে সিঙ্ক করা হয়:
- প্রথম সিঙ্কের সময়, ডিভাইসটি
10:00:00Zথেকে10:14:59Zপর্যন্ত সময়কালের একটি ডেটা পয়েন্ট আপলোড করে। - ডিভাইসে পুনঃগণনার পর, দ্বিতীয়বার সিঙ্ক করার মাধ্যমে
10:14:00Zথেকে10:28:59Zপর্যন্ত সময়কালের আরেকটি ডেটা পয়েন্ট আপলোড করা হয়।
উভয় রেকর্ডই গুগল হেলথ ব্যাকএন্ডে স্বাধীনভাবে সংরক্ষিত থাকে। ফলে, উভয় ডেটা পয়েন্টই 10:14:00Z থেকে 10:14:59Z পর্যন্ত সময়কালকে অন্তর্ভুক্ত করে। এর ফলে, র রেকর্ড কোয়েরি করার সময় ৫৯ সেকেন্ডের একটি ওভারল্যাপ তৈরি হয়।
তালিকা তুলনা করুন এবং শেষবিন্দুগুলো সমন্বয় করুন
আপনি list অথবা reconcile এন্ডপয়েন্ট ব্যবহার করে এই ওভারল্যাপিং ইন্টারভ্যালগুলো পরিচালনা করতে পারেন। আপনার অ্যাপ্লিকেশনের প্রয়োজন অনুযায়ী এন্ডপয়েন্টটি বেছে নিন:
| বৈশিষ্ট্য | list শেষবিন্দু | শেষবিন্দু reconcile |
|---|---|---|
| HTTP পদ্ধতি | GET https://health.googleapis.com/v4/users/me/dataTypes/<var>dataType</var>/dataPoints | GET https://health.googleapis.com/v4/users/me/dataTypes/<var>dataType</var>/dataPoints:reconcile |
| ওভারল্যাপ আচরণ | আপলোড করা সমস্ত সংরক্ষিত রেকর্ড ডুপ্লিকেট বাদ না দিয়ে ফেরত দেয়। যখন দুটি রেকর্ডের সময়কাল মিলে যায়, তখন উভয় রেকর্ডই ফেরত দেওয়া হয়। | বিভিন্ন ডিভাইস ও সিঙ্ক সেশনের মধ্যে থাকা দ্বন্দ্ব নিরসন করে এবং ওভারল্যাপিং রেকর্ডগুলো থেকে ডুপ্লিকেট বাদ দিয়ে সেগুলোকে একটি একক অবিচ্ছিন্ন স্ট্রিমে পরিণত করে। |
| সুবিধাগুলি | প্রতিটি ডিভাইস এবং সিঙ্ক ব্যাচ দ্বারা আপলোড করা প্রতিটি রেকর্ডের একটি সম্পূর্ণ, অপরিবর্তিত অডিট ট্রেল প্রদান করে। | ওভারল্যাপিং ইন্টারভাল এবং একাধিক ডিভাইসের দ্বন্দ্ব স্বয়ংক্রিয়ভাবে সামলানোর মাধ্যমে টাইমলাইন রেন্ডারিং ও সময়কাল গণনাকে সহজ করে তোলে। |
| অসুবিধা | আপনার অ্যাপ্লিকেশনটি ওভারল্যাপিং ইন্টারভাল, একাধিক ডিভাইসের মধ্যে দ্বন্দ্ব এবং কব্জি থেকে দূরে থাকার সময়কাল শনাক্ত ও সমাধান করার জন্য দায়ী। | অধীনস্থ ও ওভারল্যাপিং রেকর্ডগুলো রেসপন্স থেকে বাদ দেওয়া হয়, ফলে স্বতন্ত্র ডিভাইস সিঙ্ক ব্যাচগুলোকে বিচ্ছিন্নভাবে নিরীক্ষা করা যায় না। |
reconcile এন্ডপয়েন্টটি ইউজার ইন্টারফেস আঁকা, অ্যাক্টিভিটি টাইমলাইন রেন্ডার করা এবং ওভারল্যাপবিহীন মোট সময়কাল গণনা করার জন্য ডিজাইন করা হয়েছে। এটি রি-বাকেটেড সিঙ্ক সেশন থেকে আসা পরস্পরবিরোধী ইন্টারভ্যালগুলোর সমাধান করে। এছাড়াও এটি একটি ঘড়ি এবং একটি ফোনের মতো একাধিক ডিভাইসে একই সাথে লগ করা অ্যাক্টিভিটির মধ্যে সামঞ্জস্য বিধান করে।
সমন্বয় একটি কৃত্রিম সময় সংযোগ সংশ্লেষণ করার পরিবর্তে প্রামাণিক রেকর্ডটি নির্বাচন করে পরস্পরবিরোধী সেশনগুলির সমাধান করে। উদাহরণস্বরূপ, এটি 11:00:00Z থেকে 11:30:00Z এবং 11:20:00Z থেকে 11:50:00Z কে 11:00:00Z থেকে 11:50:00Z মধ্যে একীভূত করে না। সমন্বয়কৃত প্রতিক্রিয়াটি বিজয়ী ডেটা পয়েন্টটিকে তার মূল রেকর্ডকৃত ব্যবধানসহ ফেরত দেয়। এটি সেই সেশনের পরিমাপকৃত টেলিমেট্রি এবং মেট্রিক্সের অখণ্ডতা রক্ষা করে।
চিত্র ৩-এ দেখানো হয়েছে, reconcile এন্ডপয়েন্ট কীভাবে ওভারল্যাপিং সেশনগুলো পরিচালনা করে। এটি একটি কৃত্রিম টাইম ইউনিয়ন তৈরি করার পরিবর্তে প্রামাণিক রেকর্ডটি নির্বাচন করে।
এন্ডপয়েন্টস গাইডে অনুরোধ এবং প্রতিক্রিয়ার সম্পূর্ণ উদাহরণ দেওয়া আছে। কাঁচা list রেকর্ডগুলির সাথে reconcile আউটপুট তুলনা করতে, ‘ইন্টারভাল ডেটার একটি সমন্বয়কৃত ভিউ পান’ দেখুন।
list এন্ডপয়েন্টটি ডিভাইস ডায়াগনস্টিকস এবং ডেটা অডিটের জন্য ডিজাইন করা হয়েছে। যখন আপনার ওয়ার্কফ্লোতে প্রতিটি ডিভাইস দ্বারা আপলোড করা অপরিবর্তিত রেকর্ডগুলি পরীক্ষা করার প্রয়োজন হয়, তখন এটি ব্যবহার করুন। list ব্যবহার করে কোয়েরি করার সময়, আপনার ক্লায়েন্ট লজিককে অবশ্যই র ডেটার মধ্যে থাকা যেকোনো ইন্টারভ্যাল ওভারল্যাপ পরিচালনা করতে হবে।
টাইমস্ট্যাম্পের পরিবর্তনযোগ্যতা এবং মালিকের আপডেট
সংযুক্ত ডিভাইসগুলো সাধারণ সিঙ্ক চক্রের সময় সংরক্ষিত টাইমস্ট্যাম্পগুলোকে পূর্ববর্তী তারিখ থেকে পরিবর্তন করে না। তবে, ইন্টারভ্যাল টাইমস্ট্যাম্প ( startTime এবং endTime ) সমস্ত ডেটা সোর্স জুড়ে সার্বজনীনভাবে অপরিবর্তনীয় নয়। শুধুমাত্র একটি রেকর্ডের মূল নির্মাতা বা মালিকই এর ফিল্ডগুলো পরিবর্তন করতে পারেন। অন্যান্য অ্যাপ্লিকেশনগুলো এমন ডেটা পয়েন্ট সম্পাদনা করতে পারে না যা তারা তৈরি করেনি।
একটি মালিক অ্যাপ্লিকেশন তার বিদ্যমান রেকর্ডগুলি আপডেট করতে patch এন্ডপয়েন্ট ব্যবহার করতে পারে। এর মধ্যে শুরু বা শেষের টাইমস্ট্যাম্প পরিবর্তন করাও অন্তর্ভুক্ত। PATCH ব্যবহার করে টাইমস্ট্যাম্প আপডেট করার একটি উদাহরণের জন্য, এন্ডপয়েন্টস গাইডের "বিদ্যমান ডেটার জন্য ব্যবধানের টাইমস্ট্যাম্প আপডেট করুন" অংশটি দেখুন।
একইভাবে, হেলথ কানেক্ট বা পার্টনার অ্যাপের মতো বাহ্যিক প্ল্যাটফর্ম থেকে সিঙ্ক করা ডেটা পয়েন্টগুলো মূল উৎস থেকে আপডেট গ্রহণ করে। যখন মূল অ্যাপ্লিকেশনটি কোনো বিদ্যমান রেকর্ড পরিবর্তন করে, তখন সেই আপডেটগুলো গুগল হেলথ-এ ছড়িয়ে পড়ে।