งานเชื่อมแอปของคุณเข้ากับคลังข้อมูลสุขภาพที่อยู่ในเครื่องของผู้ใช้อยู่แล้ว ทั้ง Apple Health ผ่าน HealthKit บน iPhone และ Apple Watch และ Health Connect กับ Google Fit บน Android และ Wear OS รวมถึงอุปกรณ์อย่าง Fitbit, Garmin และนาฬิกาของ Samsung ที่เขียนค่าลงคลังเหล่านี้ สิ่งที่อ่านได้มีตั้งแต่จำนวนก้าวและระยะทาง การออกกำลังกาย พลังงานที่ใช้ ค่าจากหัวใจ การนอนที่แยกเป็นช่วง ไปจนถึงน้ำหนักและระดับน้ำตาลในเลือดเมื่อมีเครื่องวัดเขียนค่าเข้ามา ทั้งหมดนี้เกิดขึ้นได้ต่อเมื่อผู้ใช้กดให้สิทธิ์เท่านั้น และงานส่วนที่ยากที่สุดไม่ใช่การเรียก API แต่คือการรับข้อมูลที่มาเป็นชุด มาช้า มาไม่เรียงเวลา และซ้ำกันจากหลายแหล่ง ให้กลายเป็นตัวเลขชุดเดียวที่เชื่อได้ แล้ววางไว้ข้างสิ่งที่มีความหมายกับผู้ใช้คนนั้น
เหมาะกับใคร
ธุรกิจสุขภาพ ฟิตเนส และโภชนาการที่มีแอปของตัวเองหรือกำลังจะทำ คลินิกและโรงพยาบาลที่มีแอปฝั่งผู้ป่วย และองค์กรที่ทำโครงการดูแลสุขภาพพนักงาน ซึ่งอยากให้แอปรู้จักกิจกรรมและการนอนของผู้ใช้จากอุปกรณ์ที่เขาใช้อยู่แล้ว แทนการให้กรอกเองทุกวัน
อ่านอะไรได้บ้าง และข้อมูลนั้นมาจากไหน
ข้อมูลสุขภาพส่วนใหญ่ไม่ได้อยู่ที่ผู้ผลิตอุปกรณ์ แต่อยู่ในคลังกลางบนเครื่องของผู้ใช้เอง บน iPhone และ Apple Watch คือ Apple Health ซึ่งแอปเข้าถึงผ่าน HealthKit ส่วนบน Android และ Wear OS คือ Health Connect และ Google Fit นาฬิกาและอุปกรณ์สวมใส่อย่าง Fitbit, Garmin หรือของ Samsung จะเขียนค่าที่วัดได้ลงคลังเหล่านี้ แอปของคุณจึงอ่านจากที่เดียวได้ ไม่ต้องไล่ต่อ API ของผู้ผลิตทีละราย และไม่ต้องแก้แอปใหม่ทุกครั้งที่ผู้ใช้เปลี่ยนยี่ห้อนาฬิกา
ชนิดข้อมูลที่อ่านได้ครอบคลุมกิจกรรมประจำวันอย่างจำนวนก้าวและระยะทาง การออกกำลังกายที่บอกทั้งประเภทและระยะเวลา พลังงานที่ใช้ระหว่างเคลื่อนไหวและพลังงานพื้นฐานขณะพัก ค่าจากหัวใจทั้งอัตราการเต้นระหว่างวัน อัตราการเต้นขณะพัก และความแปรปรวนของอัตราการเต้นหัวใจ ระดับออกซิเจนในเลือด การนอนที่แยกเป็นช่วงหลับพร้อมเวลาเข้านอน เวลาตื่นและระยะเวลารวม น้ำหนักและองค์ประกอบร่างกาย ไปจนถึงระดับน้ำตาลในเลือดในกรณีที่มีเครื่องวัดของผู้ใช้เขียนค่าเข้าคลัง สิ่งที่ต้องสำรวจก่อนออกแบบฟีเจอร์คือผู้ใช้กลุ่มเป้าหมายใช้อุปกรณ์อะไร เพราะค่าอย่างความแปรปรวนของอัตราการเต้นหัวใจ ออกซิเจนในเลือด หรือช่วงการนอน ขึ้นกับว่าอุปกรณ์นั้นวัดและเขียนลงคลังจริงหรือไม่ ไม่ใช่ทุกเครื่องจะมีครบ
- กิจกรรม: จำนวนก้าว ระยะทาง และการออกกำลังกายพร้อมประเภทและระยะเวลา
- พลังงาน: พลังงานที่ใช้ระหว่างเคลื่อนไหว และพลังงานพื้นฐานขณะพัก
- หัวใจ: อัตราการเต้นระหว่างวัน อัตราการเต้นขณะพัก และความแปรปรวนของอัตราการเต้นหัวใจ
- การนอน: แยกเป็นช่วงหลับ พร้อมเวลาเข้านอน เวลาตื่น และระยะเวลารวม
- ร่างกาย: น้ำหนัก องค์ประกอบร่างกาย และระดับออกซิเจนในเลือด
- ระดับน้ำตาลในเลือด เมื่อมีเครื่องวัดของผู้ใช้เขียนค่าเข้าคลัง
สิทธิ์เป็นของผู้ใช้ ไม่ใช่ของแอป
ผู้ใช้ให้สิทธิ์แยกเป็นรายชนิดข้อมูล จะให้เฉพาะจำนวนก้าวแต่ไม่ให้อัตราการเต้นหัวใจก็ได้ จะให้สิทธิ์อ่านโดยไม่ให้สิทธิ์เขียนกลับก็ได้ และถอนคืนเมื่อไรก็ได้จากหน้าตั้งค่าของระบบปฏิบัติการ โดยไม่ต้องเปิดแอปของคุณเลย เราจึงขอสิทธิ์เฉพาะชนิดที่ฟีเจอร์นั้นใช้จริง ขอในจังหวะที่ผู้ใช้กำลังจะใช้ฟีเจอร์นั้น และบอกให้ชัดว่าเอาไปทำอะไร แทนการขอทุกอย่างรวดเดียวตั้งแต่เปิดแอปครั้งแรก ซึ่งเป็นจังหวะที่คนกดปฏิเสธมากที่สุด
ข้อจำกัดที่เปลี่ยนวิธีออกแบบหน้าจอคือ บน iOS แอปไม่มีทางรู้ว่าผู้ใช้ปฏิเสธสิทธิ์อ่าน หรือแค่ไม่มีข้อมูลชนิดนั้นอยู่จริง เพราะทั้งสองกรณีคืนค่าว่างออกมาเหมือนกัน และเป็นเช่นนั้นโดยเจตนา เพื่อไม่ให้แอปอนุมานสถานะสุขภาพจากการที่ผู้ใช้ปฏิเสธ หน้าจอตอนไม่มีข้อมูลจึงต้องเขียนให้ครอบคลุมทั้งสองความหมาย ไม่กล่าวหาว่าผู้ใช้ไม่ให้สิทธิ์ แต่เปิดทางไว้สองทาง คือทางลัดไปหน้าตั้งค่าเพื่อตรวจสิทธิ์ และช่องกรอกค่าเองสำหรับคนที่ยังไม่อยากเชื่อมต่อ พูดกันตรง ๆ ว่านี่คือการเชื่อมต่อที่ตั้งอยู่บนการขออนุญาต ไม่ใช่วิธีเข้าถึงข้อมูลสุขภาพของใครโดยที่เจ้าตัวไม่รู้ ถ้าผู้ใช้ไม่ให้ ก็ไม่มีข้อมูล และระบบต้องยังทำงานต่อได้ในกรณีนั้น
- ขอสิทธิ์แยกรายชนิดข้อมูล เฉพาะชนิดที่ฟีเจอร์นั้นใช้จริง
- ขอในจังหวะที่ผู้ใช้กำลังจะใช้ฟีเจอร์ พร้อมอธิบายว่าเอาไปทำอะไร
- รองรับกรณีที่ผู้ใช้ให้สิทธิ์อ่านอย่างเดียว โดยไม่ให้เขียนกลับ
- ผู้ใช้ถอนสิทธิ์ได้ตลอดเวลาจากหน้าตั้งค่าของเครื่อง แอปต้องรับสภาพนั้นได้
- บน iOS แยกไม่ออกว่าถูกปฏิเสธหรือไม่มีข้อมูล หน้าจอว่างจึงต้องเขียนให้ครอบคลุมทั้งสองแบบ
- ทุกฟีเจอร์หลักยังต้องใช้งานได้เมื่อไม่ได้รับสิทธิ์ ด้วยการกรอกค่าเอง
ข้อมูลไม่ได้ไหลเข้ามาแบบสด แต่มาเป็นชุด มาช้า และมาซ้ำ
ความเข้าใจผิดที่ทำให้ระบบพังบ่อยที่สุดคือคิดว่าค่าจากนาฬิกาจะเข้ามาทันทีที่วัดได้ ของจริงคือข้อมูลมาเป็นชุดตอนที่นาฬิกาซิงก์กับมือถือ ซึ่งอาจเป็นหลายชั่วโมงหลังจากนั้น การนอนของเมื่อคืนอาจโผล่มาตอนสาย การออกกำลังกายของเมื่อวานอาจถูกเติมย้อนหลังเข้ามาหลังจากที่ระบบสรุปยอดของวันนั้นไปแล้ว และลำดับที่ข้อมูลมาถึงก็ไม่ตรงกับลำดับเวลาที่วัด ระบบจึงต้องออกแบบโดยถือว่าตัวเลขของเมื่อวานยังเปลี่ยนได้ และคำนวณค่าสรุปใหม่เมื่อมีข้อมูลเข้ามาเพิ่ม แทนการปิดยอดของวันแล้วถือว่าจบ
อีกเรื่องคือค่าซ้ำ การออกกำลังกายครั้งเดียวปรากฏเป็นสองรายการได้ เพราะทั้งมือถือและนาฬิกาต่างเขียนของตัวเองลงคลัง หรือเพราะแอปของอีกยี่ห้อเขียนซ้ำเข้าไปอีกชุดหนึ่ง เราจึงเก็บตัวระบุของแต่ละค่าที่คลังให้มา พร้อมแหล่งที่มาและช่วงเวลา แล้วตัดซ้ำด้วยกฎที่ตกลงกันไว้ล่วงหน้า เช่น เลือกแหล่งหลักหนึ่งแหล่งต่อหนึ่งตัววัดในช่วงเวลาที่ทับกัน เราแยกเวลาที่วัดออกจากเวลาที่ระบบรับ และเก็บเขตเวลาไว้ด้วย เพราะการนอนที่คาบเที่ยงคืนและการเดินทางข้ามเขตเวลาทำให้การนับเป็นรายวันเพี้ยนได้ง่าย และเมื่อผู้ใช้ลบค่าใดออกจากคลัง สำเนาฝั่งเราต้องถูกลบตามด้วย
- ซิงก์แบบเพิ่มทีละรอบ ไม่ดึงทั้งคลังใหม่ทุกครั้ง
- เก็บตัวระบุของแต่ละค่าและแหล่งที่มา รับข้อมูลซ้ำได้โดยไม่นับซ้ำ
- มีกฎตัดข้อมูลซ้ำ สำหรับกรณีที่มือถือและนาฬิกาเขียนกิจกรรมเดียวกัน
- แยกเวลาที่วัดออกจากเวลาที่ระบบรับ และเก็บเขตเวลาไว้ด้วย
- คำนวณค่าสรุปรายวันใหม่เมื่อข้อมูลย้อนหลังมาถึงทีหลัง
- ลบข้อมูลฝั่งเราตามเมื่อผู้ใช้ลบค่านั้นออกจากคลัง
คุณค่าอยู่ที่ตัวเลขถูกวางไว้ข้างอะไร และการดูแลข้อมูลตาม PDPA
วันนี้เดินไปกี่ก้าวเป็นตัวเลขที่ผู้ใช้เปิดดูในแอปสุขภาพของเครื่องได้อยู่แล้ว การดึงมาแสดงซ้ำเฉย ๆ จึงไม่ได้เพิ่มอะไรให้เขา สิ่งที่เพิ่มคือการวางค่าเหล่านั้นไว้ข้างสิ่งอื่นที่มีความหมายกับเขา เช่น วางการนอนไว้ข้างปริมาณงานหรือตารางซ้อมของสัปดาห์นั้น วางกิจกรรมไว้ข้างเป้าหมายโภชนาการของวัน หรือแสดงอัตราการเต้นหัวใจขณะพักเป็นแนวโน้มต่อเนื่องหลายสัปดาห์แทนค่าของวันนี้เพียงค่าเดียว นี่เป็นรูปแบบเดียวกับที่เราใช้ในแอป HEALTH ME ซึ่งวางบันทึกอาหารไว้ข้างผลตรวจเลือดพร้อมช่วงอ้างอิงและกราฟแนวโน้ม เพราะตัวเลขตัวเดียวไม่ได้บอกอะไร แต่ตัวเลขที่มีของให้เทียบบอกได้ และต้องระบุให้ชัดในตัวผลิตภัณฑ์ว่าสิ่งนี้ช่วยให้ผู้ใช้เห็นภาพของตัวเอง ไม่ใช่การวินิจฉัย และไม่ได้แทนคำแนะนำของแพทย์
ข้อมูลสุขภาพเป็นข้อมูลส่วนบุคคลอ่อนไหวตาม PDPA และการที่ระบบปฏิบัติการยอมให้แอปอ่านได้ ไม่ได้แปลว่าองค์กรมีฐานการประมวลผลที่ถูกต้องแล้ว ความยินยอมต้องชัดเจนและเจาะจง บอกว่าเก็บอะไร เพื่ออะไร เก็บนานแค่ไหน และใครเห็นได้บ้าง แยกออกจากการกดยอมรับเงื่อนไขการใช้บริการรวม ๆ เราออกแบบให้เก็บเท่าที่ฟีเจอร์ต้องใช้จริง หลายกรณีเก็บเป็นค่าสรุปรายวันก็พอ ไม่ต้องคัดลอกค่าดิบทุกจุดขึ้นเซิร์ฟเวอร์ และบางงานประมวลผลบนเครื่องผู้ใช้แล้วส่งขึ้นมาเฉพาะผลลัพธ์ได้ ที่เหลือคือพื้นฐานที่ต้องมีตั้งแต่วันออกแบบ ได้แก่ การเข้ารหัสทั้งตอนส่งและตอนจัดเก็บ การจำกัดว่าใครในองค์กรเข้าถึงได้ นโยบายระยะเวลาเก็บและการลบเมื่อครบกำหนด และปุ่มที่ให้ผู้ใช้ถอนความยินยอม ขอสำเนา และลบข้อมูลของตัวเองได้จริงจากในแอป ไม่ใช่ต้องเขียนอีเมลมาขอ
- วางค่าที่อ่านได้ไว้ข้างเป้าหมาย ภาระงาน หรือผลตรวจ ให้ตีความต่อได้
- แสดงเป็นแนวโน้มต่อเนื่องหลายสัปดาห์ ไม่ใช่ค่าของวันนี้ค่าเดียว
- ระบุให้ชัดว่าเป็นข้อมูลเพื่อการติดตามตัวเอง ไม่ใช่การวินิจฉัย
- ความยินยอมแยกเฉพาะเรื่อง ระบุวัตถุประสงค์และระยะเวลาเก็บ
- เก็บเท่าที่ใช้ เช่น เก็บค่าสรุปรายวันแทนค่าดิบทุกจุด
- เข้ารหัสข้อมูล จำกัดสิทธิ์เข้าถึงภายในองค์กร และลบเมื่อครบกำหนด
- ผู้ใช้ถอนความยินยอม ขอสำเนา และลบข้อมูลของตัวเองได้จากในแอป
ความสามารถหลัก
- อ่านข้อมูลจาก Apple Health ผ่าน HealthKit บน iPhone และ Apple Watch
- อ่านข้อมูลจาก Health Connect และ Google Fit บน Android และ Wear OS
- รับค่าจากอุปกรณ์ที่เขียนเข้าคลังกลาง เช่น Fitbit, Garmin และนาฬิกาของ Samsung
- ครอบคลุมก้าว การออกกำลังกาย พลังงาน หัวใจ การนอน น้ำหนัก และน้ำตาลในเลือด
- ขอสิทธิ์แยกรายชนิดข้อมูล ในจังหวะที่ผู้ใช้กำลังจะใช้ฟีเจอร์นั้น
- หน้าจอยังทำงานได้เมื่อผู้ใช้ไม่ให้สิทธิ์ หรือเมื่อยังไม่มีข้อมูล
- ซิงก์เพิ่มทีละรอบ พร้อมตัดข้อมูลซ้ำจากหลายแหล่งด้วยตัวระบุของแต่ละค่า
- รองรับข้อมูลที่มาช้าและมาไม่เรียงเวลา พร้อมคำนวณค่าสรุปรายวันใหม่
- วางค่าที่อ่านได้ไว้ข้างเป้าหมาย ภาระงาน หรือผลตรวจ ให้ตีความต่อได้
- ความยินยอมที่ระบุวัตถุประสงค์ ถอนได้ และลบข้อมูลได้ตาม PDPA
อยากได้ระบบแบบนี้
เล่าโจทย์ให้เราฟัง แล้วเราจะช่วยประเมินว่าต้องปรับอะไรให้เข้ากับงานของคุณ