Patient Portal OAuth: จัดการสิทธิ์ผู้ป่วยใน Node.js

การใช้งาน OAuth สำหรับระบบพอร์ทัลผู้ป่วยช่วยให้ผู้ใช้งานรู้สึกคุ้นเคย แต่ยังคงมีโจทย์สำคัญว่าแอปพลิเคชันควรเข้าถึงข้อมูลสุขภาพเฉพาะส่วนในขณะนั้นหรือไม่ คำแนะนำหลักคือควรแยกการตัดสินใจระหว่างการยืนยันตัวตน ความยินยอม และอายุของเซสชันออกจากกันอย่างเด็ดขาด นักพัฒนาสามารถเลือกใช้ผู้ให้บริการแบบจัดการสำเร็จรูป (managed provider) หากนโยบายและความปลอดภัยตรงกับความเสี่ยง หรือเลือกใช้ระบบที่ปรับแต่งได้เมื่อต้องการควบคุมการหมุนเวียนโทเค็นและบันทึกเหตุการณ์ (audit events) อย่างรัดกุม

สำหรับการย้ายระบบออกจากผู้ให้บริการเดิม ขั้นตอนแรกคือการกำหนดขอบเขตและรันการทำงานแบบคู่ขนานทีละส่วนอย่างระมัดระวัง ห้ามย้ายข้อมูลคอลแบ็กและฐานข้อมูลทั้งหมดในคราวเดียว เพราะความต่อเนื่องของบัญชีผู้ใช้มีความสำคัญมากกว่าการเร่งกำหนดการย้ายระบบให้เสร็จสิ้นโดยเร็ว

ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง

กระบวนการคอลแบ็กของ OAuth ควรถูกมองว่าเป็นเหตุการณ์ยืนยันตัวตน ไม่ใช่สิทธิ์ในการเข้าถึงแบบครอบจักรวาล ก่อนที่จะขอเข้าถึงข้อมูล ระบบควรแสดงหมวดหมู่ วัตถุประสงค์ และการกระทำที่จะทริกเกอร์การอ่านข้อมูลให้ผู้ใช้ทราบอย่างชัดเจน เช่น การระบุว่า "ประวัติการใช้ยา ใช้เพื่อเติมฟอร์มขอใบสั่งยาอัตโนมัติเมื่อเปิดใช้งาน" ดีกว่าการใช้ข้อความกว้างๆ เช่น "เพื่อปรับปรุงประสบการณ์ของคุณ"

เมื่อกระบวนการคอลแบ็กสร้างหรือค้นพบบัญชีผู้ใช้ในระบบแล้ว จะต้องตรวจสอบสถานะความยินยอมก่อนแตะต้องข้อมูลที่มีการป้องกัน สถานะความยินยอมอาจเป็น ยินยอม เพิกถอน หรือไม่มีข้อมูล และส่วนติดต่อผู้ใช้จะต้องสอดคล้องกับสถานะดังกล่าวแม้ว่าแท็บเบราว์เซอร์จะไม่ได้ใช้งานเป็นเวลานาน การคลิกเพิกถอนที่เปลี่ยนแค่ช่องทำเครื่องหมายบนหน้าจอถือเป็นข้อบกพร่องด้านความปลอดภัย เนื่องจาก API ในลำดับถัดไปอาจยังคงประมวลผลข้อมูลอยู่

"Medication history, used to pre-fill the refill form when you open it" is concrete. “Improve your experience” is not.

Linus Holm

บันทึกการตรวจสอบ (audit record) ควรบันทึกการเปลี่ยนผ่านสถานะ หมวดหมู่ ผู้กระทำ ประทับเวลา และตัวระบุคำขอ ในส่วนของการหมุนเวียนรีเฟรชโทเค็น (refresh-token rotation) กำหนดให้นำออกโทเค็นใหม่ทุกครั้งที่มีการรีเฟรช ยกเลิกโทเค็นก่อนหน้า และยกเลิกเซสชันทันทีหากสงสัยว่ามีการเล่นซ้ำ (replay) หรืออุปกรณ์ถูกขโมย พร้อมทั้งเก็บโทเค็นเก่าให้อย่างปลอดภัยนอกระบบบันทึกข้อมูล (logs)

ทางเลือกของผู้ให้บริการระบบยืนยันตัวตนยังมี Auth0 สำหรับองค์กรที่ต้องการความสามารถระดับสูง Clerk สำหรับทีมที่ต้องการระบบหน้าจอจัดการบัญชีสำเร็จรูป หรือ Keycloak สำหรับองค์กรที่ต้องควบคุมข้อมูลในสถานที่ตั้งของตนเอง (on-premise) อย่างไรก็ตาม ระบบเหล่านี้ไม่ได้ตัดสินใจเรื่องนโยบายข้อมูลทางคลินิกแทนทีมพัฒนาได้ ทีมงานยังคงต้องกำหนดขอบเขตการเข้าถึงข้อมูล เช่น lab_results หรือ medication_history ด้วยตนเอง

ที่มา: Dev.to