ต่อไปนี้เป็นบทความรับเชิญโดย Mark Scrimshire ประธานเจ้าหน้าที่ฝ่ายการทำงานร่วมกันของ Onyx
ในขณะที่อุตสาหกรรมดำเนินการตามกำหนดเวลาการปฏิบัติตาม CMS-0057 ปัญหาพื้นฐานก็กำลังเกิดขึ้น: แนวทางปัจจุบันของเราในด้านอัตลักษณ์และความไว้วางใจขององค์กรไม่ได้รับการออกแบบมาเพื่อระดับการแลกเปลี่ยนที่ขับเคลื่อนด้วย API ที่กฎระเบียบนี้กำหนด เราสามารถสร้าง API ปรับใช้โปรไฟล์ และเตรียมขั้นตอนการทำงานได้ แต่ไม่มีวิธีที่เชื่อถือได้ในการตรวจสอบ WHO อยู่ที่อีกด้านหนึ่งของธุรกรรม ความสามารถในการทำงานร่วมกัน โดยเฉพาะอย่างยิ่งการลงทะเบียนเพื่อการเข้าถึง จะยังคงขึ้นอยู่กับกระบวนการแบบแมนนวลที่ไม่ได้ปรับขนาด
ปัจจุบัน ผู้ชำระเงินและผู้ให้บริการพึ่งพาวิธีการต่างๆ มากมายเพื่อสร้างความน่าเชื่อถือ: สเปรดชีต ไดเร็กทอรีแบบคงที่ แบบฟอร์มการรับรอง เวิร์กโฟลว์การเริ่มต้นใช้งานที่กำหนดเอง และหลักปฏิบัติด้านใบรับรองที่แตกต่างกันอย่างกว้างขวางทั่วทั้งระบบนิเวศ วิธีการเหล่านี้สามารถทำงานได้ในความสัมพันธ์ทวิภาคี แต่จะพังเมื่ออุปกรณ์หลายพันเครื่องต้องโต้ตอบผ่าน FHIR API ที่เป็นมาตรฐานสำหรับผู้จ่ายต่อผู้ชำระเงิน การเข้าถึงของผู้ให้บริการ และการแลกเปลี่ยนการอนุญาตก่อนหน้า
ความจริงนั้นง่ายมาก: ความสามารถในการทำงานร่วมกันไม่สามารถปรับขนาดได้หากไม่มีตัวตน และตัวตนในบริบทนี้จะต้องสามารถตรวจสอบได้ พกพาได้ และยึดอยู่ในกรอบความไว้วางใจที่สอดคล้องกัน
UDAP ช่วยได้ แต่ก็ยังทำให้เกิดช่องว่าง
คู่มือการดำเนินการด้านความปลอดภัย FAST/UDAP ถือเป็นก้าวสำคัญที่ก้าวไปข้างหน้า สร้างมาตรฐานให้กับวิธีที่องค์กรตรวจสอบสิทธิ์และลงทะเบียนลูกค้าโดยใช้ใบรับรอง, JSON Web Tokens และนโยบายชุมชนที่เชื่อถือได้ TEFCA ได้รวม UDAP ไว้แล้ว และการใช้งานที่สอดคล้องกับ CMS ก็ตามมาติดๆ
แต่ UDAP เพียงอย่างเดียวไม่สามารถแก้ปัญหาที่ยืดเยื้อได้ เนื่องจากการดูแลสุขภาพยังขาดตัวระบุองค์กรที่เป็นที่ยอมรับในระดับสากลและตรวจสอบได้ ใบรับรองสามารถบอกเราว่าเอนทิตีควบคุมโดเมนหรือได้รับการตรวจสอบโดยผู้ออกใบรับรองรายใดรายหนึ่ง แต่ไม่ได้ตอบคำถามเชิงลึกอย่างสม่ำเสมอ:
- องค์กรนี้เป็นนิติบุคคลที่ถูกต้องตามกฎหมายหรือไม่
- มันใช้งานอยู่และอยู่ในสภาพดีหรือไม่?
- มีอำนาจดำเนินการในบทบาทนี้หรือไม่?
- มันเป็นส่วนหนึ่งของเครือข่าย โปรแกรม หรือข้อตกลงตามสัญญาที่เฉพาะเจาะจงหรือไม่?
คำถามเหล่านี้คือคำถามที่ทุกวันนี้ได้รับคำตอบผ่านกระบวนการที่ต้องทำด้วยตนเอง ไม่ใช่การเชื่อถือแบบอัตโนมัติ
vLEI: รากฐานสำหรับการระบุตัวตนที่ตรวจสอบได้
Verifiable Legal Entity Identifier (vLEI) พัฒนาโดย Global Legal Entity Identifier Foundation (GLEIF) นำเสนอหนทางข้างหน้า ระบบ LEI ถูกนำมาใช้ทั่วโลกแล้วในตลาดการเงินเพื่อระบุนิติบุคคล องค์กรด้านการดูแลสุขภาพหลายแห่งมี LEI อยู่แล้ว vLEI ขยายขอบเขตนี้ไปสู่ข้อมูลรับรองดิจิทัลที่ตรวจสอบได้ด้วยการเข้ารหัส ซึ่งเชื่อมโยงข้อมูลประจำตัวขององค์กรกับคู่คีย์ที่ปลอดภัย
สำหรับการดูแลสุขภาพ สิ่งนี้สำคัญเนื่องจาก vLEI มอบ:
- ตัวระบุองค์กรที่ไม่ซ้ำทั่วโลก
- หลักฐานการเข้ารหัสลับของสถานะนิติบุคคล
- การมอบหมายที่ตรวจสอบได้ให้กับบุคคลหรือระบบที่ทำหน้าที่ในนามของกิจการ
- ข้อมูลระบุตัวตนแบบพกพาที่ทำงานข้ามชุมชนแห่งความไว้วางใจ
เมื่อรวมกับ UDAP แล้ว vLEI สามารถลดหรือขจัดขั้นตอนที่ต้องดำเนินการเองซึ่งเราใช้อยู่ในปัจจุบันในการเริ่มใช้งาน การตรวจสอบ และการอนุญาต แทนที่จะให้ผู้ชำระเงินหรือผู้ให้บริการแต่ละรายตรวจสอบการเชื่อมต่อใหม่แต่ละรายการด้วยตนเอง ระบบสามารถพึ่งพาเฟรมเวิร์กความไว้วางใจที่ใช้ร่วมกันพร้อมห่วงโซ่การรักษาความปลอดภัยที่ชัดเจน
ขยายความไว้วางใจในเครือข่าย
ในการดูแลสุขภาพ อัตลักษณ์ไม่ได้เป็นเพียงการจัดองค์กรเท่านั้น แต่เป็นบริบท ข้อมูลส่วนใหญ่ที่มีการแลกเปลี่ยนภายใต้ CMS-0057 ขึ้นอยู่กับโปรแกรม เครือข่าย หรือสถานะของสัญญา ตัวอย่างเช่น:
- เป็นผู้ให้บริการในเครือข่ายสำหรับผลิตภัณฑ์เฉพาะหรือไม่?
- สิ่งอำนวยความสะดวกได้รับการอนุมัติจากพันธมิตรผู้ได้รับมอบอำนาจรับรองหรือไม่?
- องค์กรเป็นผู้มีส่วนร่วมอย่างแข็งขันใน HIE, ACO หรือเครือข่ายการดูแลหรือไม่?
ปัจจุบัน ความสัมพันธ์เหล่านี้อยู่ในระบบที่เป็นกรรมสิทธิ์หรือไดเร็กทอรีแบบคงที่ซึ่งตรวจสอบได้ยากในเวลา API
ขั้นตอนถัดไปที่เป็นตรรกะคือการเปิดให้ผู้ให้บริการเครือข่าย—HIEs, ACOs, เครือข่ายผู้ให้บริการ, เอนทิตีหนังสือรับรองที่ได้รับมอบอำนาจ—ออก ข้อมูลสมาชิกเครือข่ายที่ตรวจสอบได้– ข้อมูลรับรองที่ลงนามแบบดิจิทัลเหล่านี้สามารถยืนยันสถานะของผู้ให้บริการหรือองค์กรได้ในเวลาใกล้เคียงเรียลไทม์
แทนที่จะให้ผู้ชำระเงินพยายามกระทบยอดข้อมูลจากหลายโฟลเดอร์หรือไฟล์ เซิร์ฟเวอร์การตรวจสอบความถูกต้องสามารถประเมินข้อมูลประจำตัวที่ตรวจสอบได้ในระหว่างการลงทะเบียน UDAP หรือกระบวนการออกโทเค็น สิ่งนี้ย้ายเราจากความไว้วางใจแบบคงที่ไปสู่ความไว้วางใจแบบไดนามิกและอิงตามหลักฐาน
สิ่งนี้หมายความว่าสำหรับ CMS-0057
การจับคู่ UDAP กับ vLEI และข้อมูลประจำตัวที่ออกโดยเครือข่ายช่วยให้หลายสิ่งที่ระบบปัจจุบันต้องเผชิญ:
- การเริ่มต้นใช้งานที่เร็วขึ้นและถูกกว่า: องค์กรต่างๆ สามารถตรวจสอบความถูกต้องของกันและกันได้โดยอัตโนมัติผ่านรากฐานของความไว้วางใจที่มีร่วมกัน
- การตัดสินใจเข้าถึงที่แม่นยำยิ่งขึ้น: การอนุญาตอาจคำนึงถึงเอกลักษณ์องค์กร บทบาท และสมาชิกเครือข่ายที่เกี่ยวข้อง ณ เวลาที่เข้าถึง
- ลดภาระการบริหาร: ควบคุมด้วยตนเองน้อยลงและเวิร์กโฟลว์การเริ่มต้นใช้งานเฉพาะกิจน้อยลง
- การตรวจสอบที่ดีขึ้น: ข้อมูลรับรองที่ตรวจสอบได้จะสร้างหลักฐานยืนยันตัวตนและอำนาจที่แข็งแกร่งยิ่งขึ้น
- เส้นทางสู่การทำงานร่วมกันในระดับชาติที่ปรับขนาดได้: เมื่อการมีส่วนร่วมขยายตัวขึ้น ชั้นข้อมูลประจำตัวแบบพกพาจะช่วยหลีกเลี่ยงต้นทุนเอ็กซ์โปเนนเชียลของความไว้วางใจแบบคู่
สารแห่งความไว้วางใจสำหรับการทำงานร่วมกันในระยะต่อไป
FHIR ได้ให้ภาษาข้อมูลทั่วไปแก่เรา UDAP มอบซองการรักษาความปลอดภัยทั่วไปให้กับเรา CMS-0057 ช่วยให้เรามีแรงผลักดันด้านกฎระเบียบไปสู่ API ที่ได้มาตรฐาน แต่หากไม่มีเลเยอร์ข้อมูลประจำตัวที่สอดคล้องกัน เราก็เสี่ยงที่จะสร้างการแตกแฟรกเมนต์แบบเดียวกับที่เราพยายามแก้ไขขึ้นมาใหม่—เฉพาะตอนนี้ที่ความเร็ว API เท่านั้น
Fabric of trust ที่สร้างขึ้นบน UDAP, vLEI และข้อมูลรับรองเครือข่ายที่ตรวจสอบได้สามารถให้:
- การปกป้องข้อมูลประจำตัวที่สอดคล้องกัน
- โมเดลการเริ่มต้นใช้งานที่ปรับขนาดได้
- การมอบหมายที่ชัดเจนและการตรวจสอบบทบาท
- สอดคล้องกับ TEFCA, CMS Aligned Networks และกฎระเบียบ CMS ในอนาคต
ความสามารถเหล่านี้จะไม่แทนที่ระบบที่มีอยู่ภายในชั่วข้ามคืน แต่สามารถลดความขัดแย้งได้อย่างมาก และเพิ่มความปลอดภัยและความน่าเชื่อถือของการแลกเปลี่ยนที่ใช้ API
เนื่องจาก CMS-0057 ช่วยเร่งการเปลี่ยนแปลงของอุตสาหกรรมไปสู่การทำงานร่วมกันแบบเรียลไทม์ ตอนนี้จึงถึงเวลาที่จะพัฒนาแนวทางทั่วไปสำหรับการระบุตัวตนทางดิจิทัล เราได้ปรับปรุงวิธีการแลกเปลี่ยนข้อมูลให้ทันสมัย ขั้นตอนต่อไปคือการปรับปรุงวิธีที่เราสร้างความไว้วางใจให้ทันสมัย
เกี่ยวกับ มาร์ค สคริมเชียร์
Mark Scrimshire เป็นประธานเจ้าหน้าที่ฝ่ายการทำงานร่วมกันของ Onyx เขาเป็นผู้มีส่วนร่วมในเฟรมเวิร์กความน่าเชื่อถือที่เป็นไปตามมาตรฐาน HL7 FHIR, FAST/UDAP และ TEFCA มายาวนาน ก่อนที่จะเป็นผู้นำโครงการริเริ่ม CMS Blue Button API และใช้เวลาในอาชีพของเขาในการพัฒนามาตรฐานการระบุตัวตน การเข้าถึง และการแลกเปลี่ยนข้อมูลในด้านการดูแลสุขภาพ