ข้ามไปที่เนื้อหา

ลายเซ็นอิเล็กทรอนิกส์ (roots_hemms_signature)

บริดจ์ Layer 3 แบบบางที่เชื่อม OCA sign_oca เข้ากับเรกคอร์ด HEMMS สองรายการที่การลงนามบนกระดาษแบบออฟไลน์สร้างปัญหามากที่สุด:

  • รายงานการตรวจสอบประจำปี ปจป. — ประธานกรรมการ + กรรมการ 2 ท่าน ลงนามภายใน Odoo พร้อมร่องรอยการตรวจสอบ แบบ chained-hash; แทนที่การส่งกระดาษไปกลับสำหรับหลักฐาน HA Thailand
  • สัญญาบริการ / MA — ผู้ขายภายนอก ลงนามผ่านลิงก์อีเมลพอร์ทัล ผู้มีอำนาจลงนามฝั่งโรงพยาบาลร่วมลงนาม ในระบบ; ไฟล์ PDF ที่ลงนามแล้วจะไปอยู่ในแชตเตอร์ (chatter) ของสัญญาโดยอัตโนมัติ

สิ่งที่คุณจะได้รับ

ฟีเจอร์ ที่ใด สถานะ
ปุ่มส่วนหัว "Send for Signature" ฟอร์มการตรวจสอบ (state=submitted) และฟอร์มสัญญา ✅ Q4.3 / Q4.4
Smart button "📝 N Sign Requests" ทั้งสองฟอร์ม ✅ Q4.3 / Q4.4
PDF qweb ที่เรนเดอร์สดในขณะลงนาม รายงานการตรวจสอบ + สรุปสัญญาใหม่ ✅ Q4.3 / Q4.4
การลงนามผ่านพอร์ทัลสำหรับผู้ขาย (ลิงก์อีเมล) เฉพาะกระบวนการสัญญา ✅ Q4.4
คำขอแบบหลายผู้ลงนาม (ลำดับใดก็ได้ — ไม่มีการกำหนดลำดับเวิร์กโฟลว์) ทั้งสอง ✅ — OQ2 ล็อกแล้ว
ร่องรอยการตรวจสอบ SHA-256 แบบ chained ต่อผู้ลงนาม ทั้งสอง — ฝังอยู่ใน sign_oca ✅
PDF ฉบับลงนามสมบูรณ์แนบไปยังแชตเตอร์ (chatter) ของเรกคอร์ดแม่ ทั้งสอง — hook _check_signed ✅ Q4.5
ตราประทับ "Digitally Signed" บนรายงานที่พิมพ์ PDF ทั้งสอง ✅ Q4.3 / Q4.4
เทมเพลตเดโมสำเร็จรูป หนึ่งเทมเพลตต่อหนึ่งโมเดลที่บริดจ์ ✅ Q4.3 / Q4.4

สิ่งที่ตั้งใจจะ "ไม่" ทำ (V1)

รายการ เหตุผล อนาคต
การลงนามอนุมัติภายใน (BME Manager / Ward / PM รายเดือน) OQ1 — ใช้กระดาษสำหรับ V1; เวิร์กโฟลว์ของโรงพยาบาลยังยอมรับกระดาษ ณ จุดเหล่านี้ Q5+
ลำดับการลงนามแบบเรียงลำดับ (เช่น ประธานต้องลงนามคนสุดท้าย) OQ2 — เพิ่มความซับซ้อนที่ไม่คุ้มค่าสำหรับ V1 Q5+
การควบคุมสถานะ (สัญญา active ต้องลงนามแล้ว) OQ3 — การลงนามเป็นแง่มุมคู่ขนาน ไม่ใช่ด่านควบคุมวงจรชีวิต Q5+
OTP / 2FA ในขณะลงนาม อยู่ในโรดแมปต้นน้ำของ sign_oca; ยังไม่ได้สร้าง Q6+
ลายเซ็นที่รับรองด้วย PKI / ETDA Level 2 อยู่ในโรดแมปต้นน้ำของ sign_oca; ยังไม่ได้สร้าง Q6+
บริดจ์บน maintenance.request OQ1 — เลื่อนการลงนามอนุมัติภายในออกไป Q5+

การวางตำแหน่งด้านการปฏิบัติตามข้อกำหนด

เครื่องมือลายเซ็นให้ระดับ เทียบเท่า ETDA Level 1: ภาพลายเซ็นบนแคนวาส พร้อมแฮช SHA-256 แบบ chained, รายการบันทึกการตรวจสอบที่ประทับ IP, และหน้าใบรับรองต่อหนึ่งคำขอ ซึ่งเพียงพอสำหรับ:

  • หลักฐานการตรวจประเมิน HA Thailand บนการตรวจสอบ ปจป. (การแทนที่ ร่องรอยกระดาษ)
  • การเก็บบันทึกภายในสำหรับสัญญารับประกัน/MA
  • การแสดงต่อผู้ตรวจสอบว่า "ใครลงนามอะไร เมื่อใด และจากที่ใด"

แต่ ไม่ เพียงพอสำหรับ:

  • ลายเซ็นที่ใช้ปกป้องได้ในชั้นศาลซึ่งต้องมีใบรับรองที่ออกโดย CA (ETDA Level ⅔)
  • สัญญาข้ามพรมแดนที่กฎหมายลายเซ็นอิเล็กทรอนิกส์แห่งชาติของผู้ลงนาม กำหนดให้ต้องมีลายเซ็นอิเล็กทรอนิกส์ที่ผ่านการรับรอง

สำหรับสถานการณ์เหล่านั้น ให้ลงนามเอกสารภายนอกผ่านผู้ให้บริการที่ได้รับ การรับรอง แล้วอัปโหลด PDF ที่ได้ไปยังแชตเตอร์ (chatter) ของเรกคอร์ดผ่าน วิดเจ็ตไฟล์แนบมาตรฐาน เลเยอร์ HEMMS ไม่ได้ขัดขวางทางสำรองนี้ — แต่เสริม ซึ่งกันและกัน

ความสัมพันธ์ระหว่างโมดูล

┌─────────────────────────────────────────────────────────────────┐
│ Layer 3 — Hospital lens                                           │
│   roots_hemms_signature  (LGPL-3, this module)                   │
│     ├ bridges hemms.asset.inspection (Q4.3)                      │
│     ├ bridges hemms.service.contract (Q4.4)                      │
│     └ extends sign.oca.request._check_signed (Q4.5)              │
└─────────────────────────────────────────────────────────────────┘
                              ▲
                              │ depends
┌─────────────────────────────────────────────────────────────────┐
│ Layer 2 — OCA building block                                      │
│   sign_oca  (AGPL-3, vendored from OCA/sign 18.0)                │
│     ├ sign.oca.template / item / role / field                    │
│     ├ sign.oca.request / signer / log                            │
│     └ OWL-based signing UI + portal + certificate report         │
└─────────────────────────────────────────────────────────────────┘