Roots Health Vertical¶

HEMMS ไม่ใช่งานครั้งเดียวจบ — มันคือผลิตภัณฑ์ที่เผยแพร่สู่สาธารณะ ตัวแรกใน health vertical ของ Trinity Roots ซึ่งเป็นความพยายามระยะยาว ในการทำ Odoo ให้เป็น vertical สำหรับโรงพยาบาลไทยทั้งในด้านคลินิกและ หลังบ้าน หน้านี้อธิบายแนวคิดเบื้องหลัง vertical นี้ ว่าทำไม HEMMS จึงกลายเป็นโอเพนซอร์ส และวิธีมีส่วนร่วมกับเราในฐานะลูกค้าหรือผู้สนับสนุน

Trinity Roots คือใคร¶

Trinity Roots Co., Ltd. เป็นพันธมิตรการนำ Odoo ไปใช้งานที่ตั้งอยู่ในกรุงเทพฯ เราส่งมอบ Odoo เป็นระบบ ERP ที่เป็นแหล่งข้อมูลหลัก ทั่วทั้งโรงพยาบาล: HR การเงิน การจัดซื้อ คลังพัสดุ — และชั้นการบำรุงรักษา / การจัดการครุภัณฑ์ ซึ่งโดยปกติแล้ว จัดการด้วยสเปรดชีตที่โรงพยาบาลไทยส่วนใหญ่

health vertical ที่ Roots เป็นการเดิมพันทั่วทั้งทีมว่า โรงพยาบาล ได้ประโยชน์จากการใช้ ERP เดียวแทนที่จะใช้ระบบคลินิกและหลังบ้าน แบบเฉพาะทางสามหรือสี่ระบบ โดยมีเงื่อนไขว่าแต่ละโมดูลของ Odoo ถูก ต่อยอดอย่างรอบคอบเพื่อให้สอดคล้องกับความเป็นจริงด้านกฎระเบียบและ ขั้นตอนการทำงานของการดูแลสุขภาพไทย HEMMS เป็นส่วนต่อยอดแรกที่เราสกัด ออกมาเป็นผลิตภัณฑ์โอเพนซอร์สที่นำกลับมาใช้ใหม่ได้

แนวคิดการทำ vertical¶

การติดตั้ง Odoo ทั่วไปให้คุณมีโมเดล maintenance.equipment และขั้นตอน maintenance.request แบบ 4 ขั้น นั่นเป็นจุดเริ่มต้นที่ดี สำหรับโรงงาน แต่มัน ไม่ใช่ สิ่งที่โรงพยาบาลไทยต้องการ:

• ไม่มีป้ายสองภาษา (ทุกฟอร์มต้องพูดได้ทั้งภาษาไทย และ อังกฤษ)
• ไม่มีโมเดลระดับความวิกฤตตามความเสี่ยง (เครื่องกระตุกหัวใจกับพัดลมตั้งโต๊ะ ไม่สามารถใช้ลำดับความสำคัญของขั้นตอนการทำงานเดียวกันได้)
• ไม่มีการติดตาม SLA ต่อขั้น (ทีม BME ถูกกำกับให้ได้ตามเวลาตอบสนอง ที่ MoPH กำหนดสำหรับเครื่องมือแพทย์วิกฤต)
• ไม่มีขั้นตอน ปจป. ประจำปี (ตรวจสอบพัสดุประจำปี — โรงพยาบาลรัฐไทย ทุกแห่งต้องส่งทะเบียนให้ผู้ตรวจสอบทุกปีงบประมาณ)
• ไม่มีรูปแบบรายงาน PM ประจำปีของ HA Thailand (มาตรฐานระบบบริการสุขภาพ ด้านที่ 6 ข้อ 6.1.4)
• ไม่มีการจัดประเภทความเสี่ยงของเครื่องมือแพทย์ที่สอดคล้องกับ MoPH (ตาราง ระดับความเสี่ยง 82 เครื่องจาก แนวทางประเมินระดับความเสี่ยงของเครื่องมือแพทย์ฯ (พ.ศ. 2564))

ช่องว่างเหล่านี้คือสิ่งที่ roots_hemms_* เติมเต็มอย่างพอดี "Hospital Lens" อยู่เป็น Layer 3 บน Odoo base และองค์ประกอบของ OCA — ดู สถาปัตยกรรม สำหรับโมเดล สามชั้นแบบเต็ม

รูปแบบการทำ vertical เดียวกันนี้ใช้ได้กับเรื่องอื่นๆ ใน ERP ของโรงพยาบาล — โมดูลการเงินต้องการการจับคู่ผังบัญชีที่สอดคล้องกับ MoPH HR ต้องการการประเมินพนักงานภาษาไทย การจัดซื้อ ต้องการการจัดประเภทผู้จำหน่ายตามกฎการจัดซื้อจัดจ้างภาครัฐ แต่ละ domain จะได้รับการปฏิบัติเดียวกัน: สกัดองค์ประกอบที่นำกลับมาใช้ใหม่ได้ ไปอัปสตรีมเมื่อทำได้ จัดชั้นการกำกับดูแลเฉพาะของโรงพยาบาลไว้ใน roots_hemms_* (หรือ vertical ที่ตั้งชื่อในลักษณะเดียวกัน) เมื่อทำไม่ได้

ทำไมจึงเป็นโอเพนซอร์ส¶

เหตุผลสามประการที่เราออกลิขสิทธิ์ภายใต้ LGPL-3 โดย vendor โมดูล OCA เข้ามา:

1. การปฏิบัติตามข้อกำหนดตรวจสอบได้เมื่อซอร์สเปิด¶

ผู้ตรวจประเมิน HA Thailand และผู้ตรวจสอบภายในมักขอ ตรรกะ เบื้องหลังตัวเลข — "ทำไมเครื่องมือแพทย์นี้ถูกจัดเป็นวิกฤต?" "SLA นี้คำนวณอย่างไร?" ด้วยโค้ดแบบปิดซอร์ส คำตอบคือ ภาพหน้าจอ ด้วย HEMMS คำตอบคือ permalink ไปยังฟังก์ชันบน GitHub ความสามารถในการปกป้องการตรวจสอบเป็นคุณสมบัติ ไม่ใช่ผลข้างเคียง

2. ลูกค้าไม่ถูกผูกขัง¶

หาก Trinity Roots หยุดสนับสนุน HEMMS โรงพยาบาลยังคงเป็นเจ้าของ ข้อมูล ฐานข้อมูล และซอร์สทรีทั้งหมดของตน เราได้เห็น ผู้ขายระบบไอทีด้านการดูแลสุขภาพแบบปิดซอร์สมากพอที่หายไปพร้อมจับ ข้อมูลของลูกค้าเป็นตัวประกัน จนเราไม่ยอมเป็นหนึ่งในนั้น

3. สอดคล้องกับ OCA หมายถึงสอดคล้องกับอัปสตรีม¶

ทุกโมดูลที่ สามารถ เป็นแบบทั่วไปได้ ถูกสร้างขึ้นบน OCA (maintenance_plan, maintenance_stock, maintenance_partner, sign_oca, ...) แทนที่จะแทนที่มัน เมื่อ OCA แก้บั๊ก HEMMS จะได้รับการแก้ไขฟรี เมื่อเราสกัดองค์ประกอบที่นำกลับมาใช้ใหม่ได้ การแก้ไขจะกลับไปยัง OCA เมื่อไม่ใช่เรื่องเฉพาะของไทย

โมดูล Layer-3 ของ roots_hemms_* เองเป็น LGPL-3 — โรงพยาบาล สามารถ fork และแก้ไขได้แบบส่วนตัวโดยไม่ถูกบังคับให้ เปิดเผยการปรับแต่งภายในของตน แต่การปรับปรุง โมดูลเองยังคงเปิด นี่คือการประนีประนอมเดียวกับที่ ใช้ได้ผลกับ psycopg2, pyparsing และไลบรารีนักพัฒนา อีกหลายสิบตัว

ลูกค้ามีส่วนร่วมอย่างไร¶

ตัว HEMMS เองดาวน์โหลดและโฮสต์เองได้ฟรี:

git clone https://github.com/jakapolr/hemms-demo
make up-private              # docker-based sandbox
make install-private         # installs every roots_hemms_* module

นอกเหนือจากนั้น Trinity Roots ให้บริการ (เรียงตามระดับการมีส่วนร่วมที่เพิ่มขึ้น):

บริการการนำไปใช้งาน

การประเมินขนาด การตั้งค่าโครงสร้างพื้นฐาน การย้ายข้อมูลจากสเปรดชีตหรือ ระบบเดิมผ่าน roots_hemms_mass_import การจับคู่ device-class ของ MoPH และการฝึกอบรมในสถานที่สำหรับ BME และบุคลากรหอผู้ป่วย

การปรับแต่งและการพัฒนาโมดูล

ส่วนขยายเฉพาะสำหรับขั้นตอนการทำงานเฉพาะของโรงพยาบาลที่ไม่ ควรอยู่ในโค้ดเบส roots_hemms_* สาธารณะ — โดยปกติเผยแพร่ เป็นโมดูลส่วนตัว roots_<customer>_* ใหม่ เราปฏิบัติตามกฎ 3 ชั้นเดียวกันสำหรับโค้ดของลูกค้าเช่นเดียวกับ HEMMS core (ดู การพัฒนาโมดูล)

การสนับสนุนต่อเนื่อง

แพ็กเกจการสนับสนุนแบบแบ่งระดับ ครอบคลุมการทดสอบการอัปเกรดกับ Odoo minor release ใหม่ แพตช์ความปลอดภัย และการตอบสนองต่อเหตุการณ์ ระดับต่างๆ มีอยู่เพื่อให้ทั้งโรงพยาบาลเอกชนขนาดเล็กและเครือข่าย โรงพยาบาลรัฐหลายสาขาต่างหาที่ที่เหมาะสมได้

โครงการเชิงกลยุทธ์แบบ vertical

สำหรับลูกค้าที่ขยายไปยัง domain อื่นใน health vertical (คลินิก การเงิน การจัดซื้อ) เราดำเนินงาน ที่สะท้อนรูปแบบ HEMMS: สกัดไปอัปสตรีมเมื่อทำได้ จัดชั้นการกำกับดูแลเฉพาะของโรงพยาบาลแยกต่างหาก

เราตั้งใจ ไม่ เผยแพร่รายการราคา — ขอบเขตการนำไปใช้งานของโรงพยาบาล แตกต่างกันมากเกินไป (จำนวนเครื่องมือแพทย์ จำนวนสาขา จำนวนการเชื่อมต่อ) จนไม่อาจมีหน้าราคาคงที่ที่มีความหมายได้ ติดต่อผ่านแบบฟอร์มติดต่อที่ https://roots.tech เพื่อขอใบเสนอราคา

การมีส่วนร่วมกลับ¶

หากคุณไม่ใช่ลูกค้าแต่อยากมีส่วนร่วม ยินดีต้อนรับ ด่าน CI (lint + การทดสอบ 177 รายการบนทุก PR — ดู CI/CD) บวกกับคู่มือ การพัฒนาโมดูล ควรครอบคลุมมาตรฐานต่างๆ เปิด discussion บน GitHub repo สำหรับสิ่งที่ ใหญ่กว่าการแก้ไขเล็กน้อย

สำหรับโรงพยาบาลไทยที่สนใจเป็นลูกค้าอ้างอิง — แบ่งปันข้อมูล device-class ที่ปกปิดตัวตน ตรวจสอบความถูกต้องของ MoPH device class ใหม่กับอัปสตรีม หรือทดลองใช้โมดูลที่ยังไม่เผยแพร่ — ติดต่อเรา ข้อมูลตั้งต้น 82 เครื่องของ MoPH ใน roots_hemms_ha_report เกิดขึ้นจาก ลักษณะนี้ และเราคาดว่าจะมีความร่วมมือเช่นนี้มากขึ้นเมื่อ vertical เติบโต