UDENTIVA แพลตฟอร์มการจัดการทันตกรรมอัจฉริยะ

คุณภาพซอฟต์แวร์และความสมบูรณ์ของกระบวนการ

กระบวนการพัฒนาซอฟต์แวร์ของเราและการปฏิบัติตาม SPICE

UDENTIVA ฝังความสมบูรณ์ของกระบวนการที่จำเป็นสำหรับซอฟต์แวร์สุขภาพไว้ในสถาปัตยกรรมเอง หน้านี้แสดงวงจรชีวิตการพัฒนา ระดับความสามารถ SPICE / ISO-IEC 15504 กลไกการบันทึกและควบคุมข้อผิดพลาดอย่างต่อเนื่อง เกณฑ์เวอร์ชันและความปลอดภัย และประวัติการพัฒนาของเรา พร้อมหลักฐาน

อ้างอิง: ระเบียบว่าด้วยระบบจัดการข้อมูลสุขภาพ (MevzuatNo 39682) มาตรา 6 และมาตรา 20 — ข้อกำหนดการรับรองคุณภาพซอฟต์แวร์ (CMMI/SPICE)

สถาปัตยกรรมกระบวนการของ UDENTIVA เป็นแนวทางการจัดการคุณภาพซอฟต์แวร์และกระบวนการที่พร้อมสำหรับการตรวจประเมิน สอดคล้องกับหลักการของ SPICE / ISO/IEC 15504

การนิยามกระบวนการ การนำไปปฏิบัติ และผลิตภัณฑ์งานที่ตรวจสอบย้อนกลับได้ถูกจัดโครงสร้างไว้แล้ว กลไกการวัดเชิงปริมาณ การป้องกันข้อบกพร่อง และการปรับปรุงอย่างต่อเนื่องกำลังดำเนินการอยู่ในการใช้งานจริง การประกาศระดับความสามารถอย่างเป็นทางการอยู่ภายใต้ขอบเขตของการประเมินโดยอิสระ (appraisal)

ระดับความสามารถ SPICE

SPICE ประเมินกระบวนการด้วยระดับความสามารถตั้งแต่ 0 ถึง 5 UDENTIVA ถูกจัดโครงสร้างให้ตอบสนองความคาดหวังของระดับ 1-3 ในเชิงนิยามกระบวนการ/การนำไปปฏิบัติ/ผลงานที่ตรวจสอบย้อนกลับได้ ส่วนระดับ 4-5 มีการดำเนินกลไกการวัดเชิงปริมาณและการปรับปรุงอย่างต่อเนื่อง การประกาศระดับอย่างเป็นทางการต้องผ่านการประเมินโดยอิสระ

Eksik (Incomplete)

กระบวนการไม่ได้ถูกนำไปปฏิบัติ/ไม่บรรลุเป้าหมาย

ดำเนินการแล้ว (Performed)

มีกระบวนการและสร้างผลลัพธ์

จัดการแล้ว (Managed)

กระบวนการถูกวางแผน ติดตาม; ผลิตภัณฑ์งานได้รับการจัดการ

ก่อตั้งแล้ว (Established)

กระบวนการมาตรฐานที่นิยามไว้ถูกนำไปใช้อย่างสอดคล้องกันทั่วทั้งโปรเจกต์

คาดการณ์ได้ (Predictable)

กระบวนการถูกควบคุมเชิงปริมาณ (ด้วยการวัด)

Optimize Eden (Optimizing)

การปรับปรุงอย่างต่อเนื่อง + การป้องกันข้อบกพร่อง + นวัตกรรมกระบวนการ

กลไกการควบคุมเชิงปริมาณและการปรับปรุงอย่างต่อเนื่องในระดับ 4-5 ดำเนินการพร้อมหลักฐาน (การวัดสด บันทึกข้อผิดพลาด/CAPA บันทึกการดีพลอย) ดังต่อไปนี้

พื้นที่กระบวนการ SPICE → การนำไปใช้ → หลักฐาน

แต่ละพื้นที่กระบวนการสอดคล้องกับการนำไปใช้จริงและหลักฐานที่ตรวจสอบได้ใน UDENTIVA กระบวนการไม่ใช่เอกสาร แต่คือโค้ดที่ทำงานจริง

พื้นที่กระบวนการ	แอปพลิเคชัน UDENTIVA	หลักฐาน
ENG.1 การเก็บรวบรวมความต้องการ	การนิยามความต้องการด้วยแผนที่เฟส + vertical slice; UDENTIVA.md ในฐานะสัญญาโปรเจกต์ล็อกความต้องการไว้	UDENTIVA.md (กฎทองคำ), 02_tech_spec/ ข้อกำหนดทางเทคนิค, แผนที่เฟส/โมดูล
ENG.4 การออกแบบซอฟต์แวร์	Modular monolith; แพ็กเกจบริบท (context) ไม่แชร์ตารางระหว่างกัน; สื่อสารผ่าน interface; บริการภายนอก = adapter	กฎขอบเขต internal/{identity,patient,billing,export,...}; ADR-001..008
ENG.5 การสร้างซอฟต์แวร์	SQL แบบเปิดเผย (sqlc, ไม่มี ORM); context เป็นพารามิเตอร์แรกในทุกฟังก์ชัน; การห่อหุ้มข้อผิดพลาด %w; ราคา = numeric	การ override ประเภทใน sqlc.yaml (numeric→string), db/queries/*.sql, gofmt/golangci-lint
ENG.6 การผสานรวมซอฟต์แวร์	สายโซ่ loopback PHP(BFF) ↔ Go ↔ PostgreSQL ↔ Redis; พื้นผิวสาธารณะเดียว	web/core/ApiClient, /healthz สุขภาพของคอมโพเนนต์ (db+redis)
ENG.7 การทดสอบซอฟต์แวร์	การทดสอบการแยก cross-tenant (สำคัญที่สุด), idempotency, การชนกันของนัดหมาย, ความแม่นยำของจำนวนเงิน, 2FA/OTP, เวกเตอร์ TOTP RFC6238, QR (การยืนยันด้วย OpenCV+ISO)	internal/integration/*_test.go, platform/totp/totp_test.go, go test ./...
SUP.1 การประกันคุณภาพ	ทุก PR ต้องปฏิบัติตามกฎทองคำ; lint สะอาด; หากการทดสอบการแยกเป็นสีแดงใน CI จะไม่มีการ merge	golangci-lint, Definition of Done kontrol listesi
SUP.8 การจัดการการกำหนดค่า	การควบคุมเวอร์ชันด้วย Git (branch core); การกำหนดเวอร์ชันสคีมาแบบเรียงลำดับด้วย goose; อาร์ติแฟกต์ build ถูกสำรองไว้	git, goose_db_version tablosu, .tools/deploy yedekleri
SUP.9 การแก้ปัญหา	บันทึกการตรวจสอบแบบ append-only + outbox อีเมล/SMS (บันทึกทุกการส่ง) + วินัยในการสำรอง/rollback การ deploy	audit_log, email_outbox/sms_outbox, bin/server.exe.bak-* rollback
SUP.10 การจัดการคำร้องขอเปลี่ยนแปลง	ทุกการเปลี่ยนแปลงสคีมาเป็น migration ที่มีหมายเลขใหม่; ย้อนกลับได้ (goose Down); การอนุมัติ classifier ของการ deploy	db/migrations/0001..0027, +goose Up/Down
MAN.3 การจัดการโปรเจกต์	การส่งมอบแบบ vertical-slice (ทุกดิ่งทำงานได้แบบครบวงจร); บันทึกการส่งต่อระหว่างเซสชัน	super-devam.md, faz tablosu (DoD per dilim)
MAN.6 การวัด	การตรวจสอบสุขภาพ, การวัดความจุ, เมตริกการส่งอีเมล/SMS, ปริมาณ audit, เทเลเมทรีเหตุการณ์แบบเรียลไทม์	/healthz, แดชบอร์ดการติดตามกระบวนการและคุณภาพ (เหตุการณ์/ข้อผิดพลาด/deploy/KPI)

สถาปัตยกรรมแบบชั้นและความปลอดภัยของข้อมูล

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

ชั้น (Layer)	ความรับผิดชอบและความปลอดภัย	ตำแหน่งที่ตั้ง
Sunum (BFF)	PHP 8.4 — BFF แบบบาง: เซสชัน, การเรนเดอร์, CSRF, การกำหนดเส้นทาง ไม่มีกฎทางธุรกิจ/DB พื้นผิวสาธารณะเดียว (IIS:443)	web/
Uygulama / Domain	Go modular monolith — ผู้มีอำนาจเพียงผู้เดียวของโดเมน RBAC, กฎทางธุรกิจ, transaction ฟังเฉพาะ 127.0.0.1 เท่านั้น	api/internal/
Veri	PostgreSQL — ทุกตารางมี tenant_id + RLS FORCE; SQL แบบเปิดเผย (sqlc), พารามิเตอร์ ราคาเป็น numeric	api/db/
แคช / คิว	Redis — เซสชัน, idempotency, ล็อกแบบกระจาย, คิว asynq (SMS/e-Fatura)	platform/redisx
Nesne Depolama	รองรับ S3 — ไฟล์ขนาดใหญ่ (ภาพเอกซเรย์) แบบ presigned/stream; blob ไม่เคยอยู่ใน DB	platform/storage
บริการภายนอก (adapter)	e-Fatura, SMS(NetGSM), อีเมล(SMTP), (ในอนาคต e-Nabız/MEDULA/DICOM) — เป็นนามธรรมอยู่หลัง interface	internal/notify

การวัดเชิงปริมาณและ KPI — เทเลเมทรีกระบวนการแบบเรียลไทม์

การวัดไม่ใช่คำแถลง แต่เป็นระบบที่ทำงานจริง ทุกการดำเนินการถูกนับแบบเรียลไทม์ (สำเร็จ/ล้มเหลว) ข้อผิดพลาดในการผลิตถูกจับไว้ในบันทึกถาวร และกรอบ KPI ด้านล่างเชื่อมกับการดำเนินการตามช่วงเวลา แหล่งข้อมูลคือตารางจริง: event_counter (ตัวนับการดำเนินการแบบเรียลไทม์), error_log (บันทึกข้อผิดพลาดถาวร), deploy_log (บันทึกการดีพลอย)

พื้นที่การวัด	KPI	เป้าหมาย	แหล่งข้อมูล	ช่วงเวลา	การกระทำ
ความปลอดภัยในการแยก tenant	cross-tenant test fail	0	CI / izolasyon testi	her PR	การบล็อกการ merge
ข้อผิดพลาดในการใช้งานจริง	ข้อผิดพลาดที่ชัดเจน (5xx/panic)	0	error_log (ถาวร)	ต่อเนื่อง/เรียลไทม์	RCA + CAPA zorunlu
อัตราความสำเร็จของธุรกรรม	success / toplam event	≥ 99%	event_counter (เรียลไทม์)	ต่อเนื่อง/เรียลไทม์	หาสาเหตุรากเมื่อลดลง
เวลาในการแก้ไข	MTTR (เวลาแก้ไขเฉลี่ย)	↓ แนวโน้มลดลง	error_log (resolved)	รายเดือน	Trend incelemesi
ความน่าเชื่อถือในการ deploy	อัตราการ rollback	< %5	deploy_log	30 วัน	Rollback review
ความปลอดภัยของตัวตน	2FA/OTP kritik olay	0	audit + event_counter	รายเดือน	การเสริมความแข็งแกร่ง
ความน่าเชื่อถือของการส่งข้อความ	SMS/e-posta failure	↓ ต่ำ	*_outbox	รายวัน	การรีวิวผู้ให้บริการ
ความพร้อมในการกู้คืน	ความสำเร็จของการทดสอบ restore	%100	DR test (hedef)	รายไตรมาส	อัปเดต Runbook

KPI เหล่านี้ถูกติดตามแบบเรียลไทม์จากแดชบอร์ด "การติดตามกระบวนการและคุณภาพ" ที่ผู้ดูแลแพลตฟอร์มเข้าถึงได้: อัตราความสำเร็จของธุรกรรม จำนวนข้อผิดพลาดที่ยังเปิดอยู่ MTTR (เวลาแก้ไขเฉลี่ย) จำนวนการดีพลอย และอัตราการ rollback

วงจรการป้องกันข้อบกพร่องและการปรับปรุงอย่างต่อเนื่อง (RCA/CAPA)

ข้อผิดพลาดในการผลิตทุกครั้งผ่านวงจรการวิเคราะห์สาเหตุที่แท้จริง (RCA) และการดำเนินการแก้ไข/ป้องกัน (CAPA) มาตรฐาน การเกิดข้อผิดพลาดเดิมซ้ำถูกป้องกันด้วยการควบคุมการถดถอย (regression) และการติดตามแนวโน้ม

บันทึกเหตุการณ์ / ข้อผิดพลาด

ข้อผิดพลาดในการใช้งานจริง (5xx/panic) ถูกจับโดยอัตโนมัติ → error_log ถาวร (เมื่อลายเซ็นเดิมเกิดซ้ำ count++, แนวโน้มข้อบกพร่อง)

การจำแนกประเภท

กำหนดระดับ (error/panic), ผลกระทบ และจำนวนครั้งที่เกิดซ้ำ; วัดความแพร่หลายด้วยตัวนับเหตุการณ์ที่ล้มเหลว

สาเหตุราก (RCA)

ทำการวิเคราะห์สาเหตุรากบนแดชบอร์ดการติดตามกระบวนการและบันทึกไว้

การดำเนินการแก้ไข/ป้องกัน (CAPA)

กำหนดและบันทึกการดำเนินการแก้ไข + การดำเนินการป้องกัน (โค้ด, การทดสอบ, กฎ migration, การควบคุมความปลอดภัย)

การควบคุมการถดถอย

เพิ่มการทดสอบ/กฎที่ป้องกันการเกิดข้อผิดพลาดเดิมซ้ำ; ติดตามด้วยเทเลเมทรีอย่างต่อเนื่อง

Trend incelemesi

ประเมินแนวโน้ม KPI (MTTR, อัตราข้อผิดพลาด, rollback) เป็นระยะ; เปิดการดำเนินการระดับกระบวนการสำหรับข้อผิดพลาดที่เกิดซ้ำ

กลไกที่ดำเนินการ — การบันทึกข้อผิดพลาด การควบคุม และการปรับปรุงอย่างต่อเนื่อง

หัวใจของ SPICE ระดับ 5 คือ การบันทึกข้อผิดพลาดอย่างต่อเนื่อง การควบคุมให้อยู่ในเกณฑ์ การป้องกันข้อบกพร่อง และการปรับปรุงอย่างต่อเนื่อง UDENTIVA ดำเนินกลไกเหล่านี้ในสภาพแวดล้อมการใช้งานจริง

การบันทึกข้อผิดพลาดอย่างต่อเนื่อง

audit_log ที่เปลี่ยนแปลงไม่ได้ (append-only) บันทึกทุกการดำเนินการที่สำคัญ; email_outbox/sms_outbox บันทึกทุกการส่ง (status, attempts, error) อย่างถาวร ไม่มีเหตุการณ์ใดสูญหายไปอย่างเงียบ ๆ

audit_log, *_outbox (status/error/attempts)

การควบคุมข้อผิดพลาดและการย้อนกลับ

ซองข้อผิดพลาดที่สอดคล้องกัน {error:{code,message}}; ข้อผิดพลาดภายใน/stack ไม่รั่วไหลออกไปเด็ดขาด ก่อนทุกการ deploy มีการสำรอง binary + web (พร้อม timestamp); เมื่อเกิด outage สามารถ rollback ได้ภายในไม่กี่วินาทีด้วย bin/server.exe.bak-*

httpx.Error, deploy yedek/rollback runbook

การป้องกันข้อบกพร่อง (Defect Prevention)

สถาปัตยกรรม fail-closed: หากไม่มีบริบท RLS จะได้ 0 แถว; idempotency ป้องกันการดำเนินการซ้ำ; จำนวนเงินแบบ numeric ทำให้ข้อผิดพลาดจาก float เป็นไปไม่ได้; whitelist (export dataset) ป้องกัน SQL injection ข้อผิดพลาดถูกป้องกันตั้งแต่ต้นด้วยการออกแบบ

RLS FORCE, Idempotency-Key SETNX, numeric, view whitelist

การตรวจสอบอิสระ

คอมโพเนนต์สำคัญได้รับการตรวจสอบด้วยสองวิธีอิสระ: เวกเตอร์ทดสอบ TOTP RFC6238, การ decode ด้วย OpenCV cv2 + codeword อ้างอิง ISO/IEC 18004 สำหรับ QR, การทดสอบการแยก cross-tenant

การทดสอบ integration + การยืนยันด้วย decoder ภายนอก

วงจรการปรับปรุงอย่างต่อเนื่อง

ในทุกเซสชัน การตรวจสอบความปลอดภัย → ข้อค้นพบ → การเสริมความแข็งแกร่ง (เช่น เพิ่ม RBAC เฟส2/เฟส3, 2FA, Export API) ความจำองค์กรได้รับการรักษาไว้ด้วยบันทึกกระบวนการ (super-devam.md)

วงจรการตรวจสอบความปลอดภัย → การเสริมความแข็งแกร่ง

นวัตกรรมกระบวนการ

คำร้องขอด้านกฎระเบียบใหม่ (VEM Görüntüsü) ถูกแปลงเป็นฟีเจอร์ผลิตภัณฑ์และหลักฐานโดยตรง; การเปลี่ยนแปลงกฎหมายถูกติดตามอย่างต่อเนื่องและบันทึกลงในแผนที่การปฏิบัติตาม

Export API/VEM views, แผนที่การปฏิบัติตาม /mevzuat

การควบคุม Edition (เวอร์ชัน)

โค้ดเบสเดียว จำกัดขอบเขตด้วยแฟล็ก — ไม่มีการ fork

ธง EDITION=base กำหนด MVP แบบคลินิกเดียว; การมองเห็นเมนู (app.php) และการเข้าถึงเส้นทาง (index.php) อ่านจาก allowlist ของ Edition::allows()
Go RBAC คือผู้มีอำนาจ; Edition เป็นเพียงการจำกัด UI/พื้นผิวเท่านั้น — สิทธิ์ที่แท้จริงถูกบังคับที่ชั้น API (การมองเห็น ≠ ความปลอดภัย)
ในเวอร์ชัน full โมดูลทั้งหมดเปิดอยู่; ในเวอร์ชัน base โมดูลการเติบโตของเฟส 2/เฟส 3 ถูกซ่อนไว้ ไม่มีการ Fork — ฐานโค้ดเดียว จำกัดด้วยธง
วัดขีดจำกัดความจุด้วยแผน/แพ็กเกจตาม tenant (โมเดลการสมัครสมาชิกแพลตฟอร์ม); เมื่อเกินขีดจำกัดจะมีคำเตือนแบบ soft (ไม่บล็อก)

กลไกการกำหนดเวอร์ชัน

เวอร์ชันที่ติดตามได้ในชั้นสคีมา ซอร์ส การดีพลอย และ API

การกำหนดเวอร์ชันสคีมา

goose migration แบบเรียงลำดับ (0001 → 0027); ทุกการเปลี่ยนแปลงมีหมายเลข + ย้อนกลับได้ (Up/Down) เวอร์ชันที่ใช้ถูกติดตามในตาราง goose_db_version การ migration ในการใช้งานจริงได้รับการยืนยันบน DB ที่สะอาด

การกำหนดเวอร์ชันซอร์ส

การควบคุมเวอร์ชันด้วย Git (branch: core); bare repo ศูนย์กลางแบบแยกอิสระ ทุกงานที่มีความหมายถูก commit; ความลับ (connection.md, .tools) อยู่ใน gitignore — ไม่มีการ commit รหัสผ่านเด็ดขาด

การกำหนดเวอร์ชันการ deploy

คอมไพล์ Go binary (-ldflags "-s -w"), swap เฉพาะ bin/server.exe เท่านั้น (ไม่ใช่ WinSW wrapper เด็ดขาด) ก่อนทุกการ deploy มีการสำรอง binary + web (พร้อม timestamp) การ cache-bust ของ static asset ด้วย ?v=N

การกำหนดเวอร์ชัน API

endpoint สาธารณะมีคำนำหน้า /v1; Export API มี /export/v1 ความเข้ากันได้ย้อนหลังได้รับการรักษาไว้; การเปลี่ยนแปลงที่ทำให้ใช้ไม่ได้คือเวอร์ชันใหม่

การใช้ Git, Rewind และ Rollback

กระบวนการพัฒนาทั้งหมดอยู่ภายใต้การควบคุมเวอร์ชัน ทุกการดีพลอยย้อนกลับได้ (rewind/rollback)

การควบคุมเวอร์ชัน

Git (branch: core); bare repo ศูนย์กลางแบบแยกอิสระ ทุกงานที่มีความหมายจะถูก commit; ประวัติสามารถตรวจสอบย้อนกลับได้

การจัดการความลับ

รหัสผ่าน/คีย์/ข้อมูลการเชื่อมต่ออยู่ใน gitignore — ไม่มีการ commit เด็ดขาด (connection.md, .tools, *.zip)

การแยกอิสระ

มีเพียงไดเรกทอรีโปรเจกต์นี้เท่านั้นที่ถูกควบคุมเวอร์ชัน ไม่มีการแตะต้องซอร์สของโปรเจกต์อื่น

การตรวจสอบย้อนกลับได้

Commit จัดตาม vertical-slice/ฟีเจอร์; บันทึกการ deploy (deploy_log) เชื่อมโยงสายโซ่ commit→release→prod

Rewind / Rollback: ก่อนทุกการดีพลอยจะมีการสำรองข้อมูล binary + เว็บ + ฐานข้อมูล (พร้อม timestamp) สคีมาเป็น migration ที่ย้อนกลับได้ (goose Down) binary ที่ทำงานอยู่สามารถย้อนกลับสู่เวอร์ชันก่อนหน้า (bin/server.exe.bak-*) ได้ภายในไม่กี่วินาที และเว็บกู้คืนจากอาร์ไคฟ์ก่อนหน้า ในกรณีเกิดเหตุ ระบบการใช้งานจริงสามารถย้อนกลับสู่สถานะเดิมที่ดีได้

เกณฑ์ความปลอดภัย (กฎทองคำ)

ความปลอดภัยไม่ใช่ฟีเจอร์ แต่คือสถาปัตยกรรมเอง กฎที่ไม่มีการต่อรอง ซึ่งหากละเมิดจะถูกปฏิเสธ PR:

การแยกระดับแถว (RLS FORCE, fail-closed)

ทุกตารางมี tenant_id; หากไม่มีบริบท policy จะคืน 0 แถว การทดสอบการแยก cross-tenant คือด่านของ CI

Atomik & idempotent yazma

การดำเนินการหลายเอนทิตีอยู่ใน transaction เดียว (ทั้งหมดหรือไม่มีเลย); ทุก mutation ป้องกันการดำเนินการซ้ำด้วย Idempotency-Key

Para = numeric

ห้ามใช้ Float; การปัดเศษที่จุดเดียว, 2 ตำแหน่ง ข้อผิดพลาดทางการเงินเป็นไปไม่ได้ด้วยการออกแบบ

ตัวตนและเซสชัน

รหัสผ่าน argon2id; session_key แบบ opaque ใน Redis (TTL แบบเลื่อน); การยืนยันตัวตนแบบสองขั้นตอน (TOTP); session_key ไม่ถูกเปิดเผยต่อเบราว์เซอร์

Topoloji izolasyonu

Go ฟังเฉพาะ 127.0.0.1; พื้นผิวสาธารณะเดียวคือ PHP/BFF พอร์ต backend (DB/Redis) ปิดไม่ให้เข้าถึงจากภายนอก

การตรวจสอบที่เปลี่ยนแปลงไม่ได้

audit_log แบบ append-only; PII/secret ไม่ถูก log/ถูกปิดบัง; TCKN/ข้อมูลสุขภาพเป็นข้อมูลอ่อนไหวพิเศษ

คำสั่งแบบมีพารามิเตอร์

SQL ทั้งหมดใช้พารามิเตอร์ (sqlc/pgx) — SQL injection เป็นไปไม่ได้; ชื่อ dataset อยู่ใน whitelist

การจัดเก็บข้อมูล (Data residency)

ข้อมูลสุขภาพอยู่ในตุรกีเท่านั้น; ไม่มีการโอนไปต่างประเทศ (KVKK ม.9, ระเบียบ KSV ม.16)

ประวัติการพัฒนา (Development History)

ระบบสร้างด้วยชิ้นส่วนแนวตั้งที่แต่ละชิ้นทำงานแบบครบวงจร ด้านล่างคือลำดับเวลาของเฟสต่าง ๆ และงานด้านความปลอดภัย/กฎระเบียบในช่วงหลัง

Faz 0 โครงกระดูก (Skeleton)

pgx+sqlc, goose, การทดสอบ RLS fail-closed, WithTenantTx, session middleware, login+RBAC, audit, loopback PHP↔Go, ฐาน asynq, health

Faz 1 แกนคลินิก (9 vertical slice)

Patient CRUD + การทดสอบการแยก cross-tenant → นัดหมาย (exclusion constraint + Redis lock) → Odontogram/แผนการรักษา (FDI, append-only) → การเรียกเก็บเงิน/บัญชีลูกหนี้/เงินสด (derive, idempotent) → adapter e-Fatura (fast-follow) → สต็อก → ภาพเอกซเรย์ (S3) → การแจ้งเตือน SMS (asynq backoff)

Platform คอนโซลการจัดการแพลตฟอร์ม

ระดับผู้ดำเนินการแพลตฟอร์ม (super-admin) (X-Platform-Key, ระนาบตัวตนแยกต่างหาก); การจัดการ tenant, โมเดลการสมัครสมาชิก/การออกใบแจ้งหนี้, การวัดความจุ, ตัวแก้ไขเวอร์ชัน legal, reCAPTCHA, การตั้งค่า NetGSM

การเติบโต หลายภาษาและเว็บไซต์คลินิก

i18n (20 dil, key-based, RTL); 20 tema + klinik public site (/s/{slug}) + lead-booking; demo klinik siteleri.

2026-06 ความปลอดภัยของตัวตนและการสื่อสาร

OTP primitive ที่ใช้ร่วมกัน; การรีเซ็ตรหัสผ่าน + magic-link + การเปิดใช้งานบัญชี (SMTP จริง); แกน NetGSM SMS; public auth แบบหลาย tenant; การจัดการผู้ใช้คลินิก

2026-06 การยืนยันตัวตนสองชั้น (2FA)

TOTP (RFC6238) + รหัสสำรอง; QR ที่บังคับใช้ (อิสระจากภายนอก, qr.js ที่สะอาดตาม CSP; ยืนยันอิสระด้วย OpenCV+ISO); การยืนยันหมายเลขโทรศัพท์ผ่าน SMS (ความยินยอม KVKK)

2026-06 การปฏิบัติตามกฎระเบียบ

VEM Görüntüsü (Minimum Veri Modeli) 12 export view + Export API (กำหนดโดย SuperUser, ล็อกตาม tenant, fail-closed); แผนที่กฎหมายและการปฏิบัติตาม; การแก้ไขสัญญา legal ให้เป็นไปตามกฎหมาย 100%

2026-06 การสนับสนุนและกระบวนการ

ศูนย์สนับสนุนที่ติดตามด้วยตั๋ว; เอกสารกระบวนการ SPICE (หน้านี้); การตรวจสอบความปลอดภัยอย่างต่อเนื่อง + การเสริมความแข็งแกร่ง

เพิ่มเติมเกี่ยวกับความสมบูรณ์ของกระบวนการและการปฏิบัติตามกฎ

สำหรับข้อมูลโดยละเอียดเกี่ยวกับสถาปัตยกรรม ความปลอดภัย และการปฏิบัติตามกฎระเบียบ โปรดติดต่อทีมงานของเรา

Regulation & Compliance ติดต่อเรา