ทำความรู้จัก H Lab
เราเป็น Health Tech Startup ที่ทำ Product หลักเป็น Hospital Management System ซึ่งเป็นตัวจัดการ Operation ภายในโรงพยาบาลซึ่งทำหน้าที่ตั้งแต่
สร้างประวัติผู้ป่วย
ระบบบันทึกข้อมูลสุขภาพของผู้ป่วย
นำเสนอข้อมูลสำหรับช่วยสนับสนุนการรักษา
จัดดการนัดหมาย การจัดการคิว
คิดเงินค่าบริการ
จัดการสิทธิประกันสุขภาพ เบิกจ่ายทั้งของรัฐ และเอกชน เรียกง่าย ๆ ว่าเป็น Core System ตัวหนึ่งของโรงพยาบาลเลย
เราทำระบบนี้ขึ้นมาเพื่อแก้ไขปัญหาของระบบเดิม ๆ 5 ด้าน
ด้าน Clinical Quality ระบบเรามีการออกแบบให้ Clinical Data เก็บอยู่ในรูปแบบที่เป็น Machine Readable ตาม Healthcare International Standard ซึ่งจากเดิมจะเป็น Free Text เป็นส่วนใหญ่ การปรับมาใช้รูปแบบนี้ช่วยให้ระบบสามารถต่อกับ AI ได้สะดวกขึ้นทั้ง AI ที่เราพัฒนาขึ้นเอง หรือของเจ้าอื่น ๆ ก็ได้ ยกตัวอย่างเช่น การแจ้งเตือน Drug Interaction ที่ต้องใช้ข้อมูลอาการ และข้อมูลโรคของผู้ป่วย ณ ขณะนั้นสามารถให้ผลที่แม่นยำกว่าการทำ Drug Interaction เฉพาะยาด้วยกันเองอย่างเดียว หรือการแจ้งเตือนเมื่อผู้ป่วยมีอาการเปลี่ยนแปลงอย่างมีนัยสำคัญ (Adverse Event Warning)ในห้องฉุกเฉิน เป็นต้น
ด้าน Finance หลาย ๆ คนคงเคยได้ยินว่าโรงพยาบาลรัฐหลาย ๆ แห่งขาดทุน ซึ่งจริง ๆ ก็เนื่องมาจาก Model การเบิกจ่ายของสิทธิประกันสุขภาพรัฐที่มีหลัก ๆ 3 แบบ แต่ละแบบก็มีความซับซ้อน อย่างไรก็ตามเมื่อข้อมูลเป็น Structure มากขึ้นก็ช่วยให้เราสามารถใช้ Algorithm ในการแนะนำข้อมูลที่ใช้สำหรับส่งเบิกให้โรงพยาบาลได้รับเงินที่ควรจะได้รับอยู่แล้วมากขึ้น
ด้าน Operation เนื่องจากการรักษาผู้ป่วยมีความหลากหลายตามโรค และอาการ บางโรคที่มีความซับซ้อนจำเป็นต้องทำงานร่วมกันหลายฝ่าย โจทย์ของเราคือการเพิ่มประสิทธิภาพการทำงานของกระบวนการที่หลากหลายนี้ ระบบเราจึงถูกออกแบบให้รองรับการปรับแต่ง Workflow ได้ และมี Dashboard ให้บริหารจัดการ Task รวมถึงตรวจสอบ Bottleneck ของระบบแบบ Realtime
ด้าน Software Performance & Security ในระบบของเราวางโครงสร้างระบบโดยแบ่งระบบเป็น Application Layer, Service Layer และ Data Layer พร้อมทั้ง Hosting ระบบอยู่บน Cloud ทำให้สามารถ Scale ได้ทั้งแบบ Horizontal ที่รองรับ request ได้มากขึ้น และ Vertical ที่ช่วยเพิ่ม resource ให้ระบบได้อย่างรวดเร็วตามสถานการณ์รวมถึงเมื่อเกิดเหตุการณ์พิเศษ นอกจากนี้ใน Service Layer ยังประกอบไปด้วยระบบ Authentication & Authorization รวมถึง Consent ของผู้ป่วย เพื่อให้การเข้าถึง และการนำข้อมูลไปใช้ถูกต้องตามจุดประสงค์ และตรวจสอบได้ ต่างจากระบบ HIS เดิมที่มักเป็น Desktop Application ต่อกับ Database โดยตรง แล้วอาจจะประเมินขนาด Database ไม่เพียงพอ ทำให้ระบบช้ามาก ๆ โดยเฉพาะช่วงเช้าที่มักมีผู้ใช้บริการมารอจำนวนมาก นอกจากนี้การไม่แบ่ง Service Layer ยังเพิ่มโอกาสที่จะโดน Hack จาก Client Computer มากขึ้น เนื่องจากมี Password Database อยู่ใน Config file ที่ใช้ต่อเข้า Database
ด้าน Health Tech Ecosystem ระบบ HIS ในปัจจุบันไม่เอื้ออำนวยให้มีระบบที่ต่อยอดจากระบบ Core system ของโรงพยาบาล เนื่องจากไม่มีทั้ง Standard Message และ Standard ในการเก็บข้อมูลที่เป็น Machine Readable แต่ภายในระบบของเราสามารถเชื่อมต่อได้ด้วย API ที่เป็น Standard FHIR และเก็บข้อมูลที่เป็น Machine Readable ด้วย Standard SNOMED CT ทำให้ Application จะของ Startup ในไทย หรือต่างชาติสามารถเข้ามาเชื่อมต่อได้ เกิดเป็น Application ดี ๆ ให้ผู้ป่วย และบุคลากรทางการแพทย์ได้ใช้อีกมากมาย ทั้งยังเป็นโอกาสให้เราสามารถแชร์ข้อมูลข้ามโรงพยาบาลได้สะดวกรวดเร็ว ถูกต้อง และมีความหมายมากขึ้นด้วย
มาดู Tech Stack เรากัน
แต่ก่อนที่จะไปอ่านรายละเอียดกัน อยากบอกก่อนว่าการมาแชร์ Tech Stack นี้ก็อยากให้ Junior ที่พึ่งเริ่ม ให้บุคลากร IT ในระบบสาธารณสุขเราได้รู้เหตุผลคร่าว ๆ เพื่อนำไปศึกษาต่อ หรือทดลองใช้กับโรงพยาบาลที่ท่านดูแล หรือให้ผู้บริหารด้าน IT ของโรงพยาบาลพอจะเข้าใจเวลาจ้าง Vendor เข้ามาทำงาน เลยอาจจะลง Detail ให้คนที่ไม่ได้รู้ Tech ลึกมากเข้าใจด้วย
Application & Service
ก่อนจะไปลงรายละเอียด Tool แต่ละตัวต้องบอกก่อนว่าปัจจุบันเราพัฒนากันในรูปแบบของ Trunk-based
development ซึ่งจะมี main branch เพียง branch เดียว เน้นการเปิด branch feature ในเวลาสั้น ๆ scope เล็ก ๆ merge เข้า branch หลัก โดย Concept คือลดปัญหาการ Integrate Code และทำให้สามารถเห็นผลงานได้เร็วขึ้น นอกจากนี้ Code เกือบทั้งหมดอยู่บน Mono Repository เพื่อให้ practice การเขึยน code ของทุกทีมเป็นไปในทางเดียวกัน เช่น Lint Rule จะมีแกนกลางอันเดียวกัน อาจจะต่างกันนิดหน่อยตาม Framework ที่ใช้ และยังช่วยให้สามารถใช้ Interface ร่วมกันระหว่าง Service หรือระหว่าง Back-end กับ Front-end ได้ด้วย มาดู Tech Stack ในระดับ Application และ Service กัน
Language : ภาษาหลักที่เราใช้จะเป็น TypeScript เพื่อให้ลดโอกาสเกิด Bug จากการลืม เขียน Code ดัก และช่วยให้ Editor สมัยใหม่สามารถช่วยแนะนำให้เราเขียนได้เร็วขึ้น (เปรียบเทียบกับ JavaScript นะ)
MonoRepo tools : เราเลือกใช้เป็น Nx ตอนที่เราเริ่มใช้ Monorepo ก็มี Nx นี่แหละที่ช่วยเรื่องการทำ local caching ทำให้ประสบการ dev บน local ดีด้วย รวมถึงมี Computational Cache ที่ช่วยให้ CI ไวขึ้น มี tool ใน GitHub Actions และสามารถรันคำสั่งเฉพาะ Application ที่มีการเปลี่ยนแปลงเท่านั้นได้ Tool อื่น ๆ อย่าง ตัวที่น่าสนใจอีกตัวที่พึ่งมาไม่นาน และมี Feature เหมือนกับ Nx เลยทีเดียวก็ Turborepo (น่าจะมาปลายปี 2021)
Front-end : ตัวหลักที่ใช้เป็น NextJS เขียนด้วยภาษา TypeScript เช่นกัน หลัก ๆ ตัวนี้การตัดสินใจจะเป็นเรื่องความถนัดความสามารถของทีมเป็นหลัก รวมถึงตลาดแรงงานในไทยด้วย ซึ่งแต่ละ Application ต้องดูความเหมาะสมด้านอื่น ๆ ด้วย
Back-end : ใช้เป็น NestJS ที่เลือกใช้ตัวนี้เพราะว่ารองรับการเขียนทั้งแบบ Object Oriented Programming, Functional Programming และ Reactive Functional Programming ทำให้สามารถจัด structure หลังบ้านได้สะดวกกว่าตาม pattern ที่ทาง NestJS แนะนำ หรือหากจะปรับแต่งก็สามารถทำ Module เพิ่มเข้าได้ ในขณะที่ถ้าใช้ Express หรือ Fastify เพียว ๆ การจะทำให้ได้รูปแบบการเขียนที่ทำให้ code สามารถดูแลได้ง่ายตามความเหมาะสมของทีม อาจจะต้องใช้เวลาในการเลือก และประกอบ library ต่าง ๆ มารวมกัน
Infrastructure & Monitoring
จริง ๆ หลาย ๆ โรงพยาบาลในปัจจุบันยัง hosting ระบบอยู่ใน On-Premise เป็นส่วนใหญ่ แต่ Application ของเรา Hosting อยู่บน Cloud ทำการเชื่อมต่อกับ On-Premise ของโรงพยาบาล ผ่าน S2S VPN หรือ Direct Connect ทำให้เสมือนเป็น Network เดียวกันกับของโรงพยาบาล
โดย Cloud หลักที่ใช้จะเป็น Azure สำหรับ Core Application (สาเหตุหลัก ๆ เพราะว่าใช้ SQL Server แล้วราคาทั้ง Stack มันถูกกว่า และ Uptime SLA ของ Database สูงถึง 99.995% เหมาะสำหรับ Business Critical Application พร้อมทั้งมี Guarantee RTO และ RPO ด้วย) และใช้ Google Cloud สำหรับ Analytics
Infrastructure as Code: ใช้ Terraform แบบ GitOps บน Terraform Cloud วิธีการนี้ช่วยระบบการทำงานเป็นทีมได้สะดวก ใครจะเปลี่ยนอะไรก็สามารถส่ง Pull Request เข้ามาตรวจสอบกันก่อนได้ สามารถรู้สถานะล่าสุดของ Infrastructure Resource ได้เสมอ อีกทั้งยังมีระบบเข้ามาช่วยตรวจสอบ configuration ว่ามีโอกาสเป็น vulnerability ด้วย ช่วยให้ปลอดภัยมากขึ้น
Kubernetes Engine: ระบบทั้งหมดรันอยู่บน Container โดยถูก Orchestrate โดย Azure Kubernetes Service ทำให้ไม่ต้อง maintain master nodes เอง และการ Upgrade version จะมีคู่มือที่ช่วยให้ Upgrade ได้สะดวก มี Feature ที่น่าสนใจคือ Pod Identity ที่ช่วยให้ workload ที่ต้องจัดการ Cloud Resource ไม่ต้องใช้ Client Id/Secret ที่ต้องคอย Rotate secret อยู่เรื่อย ๆ (ของ Google Cloud ก็มีนะชื่อว่า Workload Identity) แต่จริง ๆ เรื่อง Kubernetes service ต้องบอกว่า Google Cloud มีภาษีดีกว่า โดยมีการออก patch Kubernetes ของตัวเองที่เป็น security patch บ่อยกว่า มี Container Optimized OS ถ้าใครที่ไม่ได้ใช้ SQL Server การใช้ Kubernetes แบบที่มี Nodes ตัว Google Cloud ก็น่าสนใจ
Database: เราเลือกใช้ Azure SQL เพราะ support การ scale ภายในตัว product ของมันเอง ทำให้ลดความซับซ้อนในการ Maintain database performance ในขณะที่ MySQL ทำได้แต่ใช้ความสามารถสูง แรงเยอะ และ Postgres ไม่สามารถทำได้ด้วยตัวมันเอง แต่ตัวมันออกมาเป็นระบบที่ extend ได้ จริง ๆ Azure ก็มี Solution Citus ที่สามารถ Scale ได้เหมือนกัน แต่ถ้าดูตามตลาด Enterprise การจะหาคนมา Maintain database ดี ๆ เลือกเป็นของ Microsoft ก็น่าจะดีกว่า ทีนี้ถ้าเลือกใช้ Azure SQL ราคาของ Azure จะถูกกว่าของเจ้าอื่นมาก ๆ ในช่วงเริ่มต้นเพราะว่ามี Model ที่ขายเป็น Multi Tenant ให้ใช้ และรวมถึงแบบ Dedicated resource ก็ถูกกว่าด้วยประเภทของ VM ที่ใกล้เคียงกัน หลัก ๆ ก็น่าจะเพราะสามารถ dump ค่า License แข่งได้ ข้อดีอีกอย่างตรงนี้ก็คือถ้าทำเป็น Geo-Replicatoin Database จะมี Guarantee RTO ≤ 30s และ RPO ≤ 5s และ Uptime SLA สูงสุดจะอยู่ที่ 99.995% เหมาะสำหรับใครที่ทำ Business Critical Application
Cache: Redis ตัวนี้ตรงไปตรงมา option มีไม่มาก อีกตัวก็จะเป็น Memcached ซึ่งเหมาะสำหรับพวก session มากกว่า และเราก็มีการใช้ Feature อื่น ๆ ที่ Redis เริ่มทำได้ดีอย่าง Redis Search มาทำ complex search ด้วย
Messsage Queue: ในระบบของเราใช้ประโยชน์จาก Message Queue อยู่ 2 เหตุผลหลัก ๆ คือ ช่วยเรื่อง Realtime application และการสื่อสารระหว่าง Microservice จะขอยกตัวอย่างสักเรื่องที่ใช้บ่อย ๆ ก็จะเป็นการทำ Event Notification เป็นการส่งข้อมูลจากระบบ A ไปยัง Message Queue หากระบบ B รับทราบก็จะไปดำเนินการตาม Business Logic ที่วางไว้ โดยที่ A ไม่ต้องรอคำตอบจาก B ก็ช่วยให้ performane ของระบบ A ดี และ focus ที่เฉพาะจุดประสงค์หลัก ๆ ของ service A ทีนี้ถ้าหากมีระบบ C ต้องการข้อมูลเช่นเดียวกันกับ B แต่เป็นคนละจุดประสงค์กับ Service B ก็สามารถ Extend ระบบได้เลย โดยที่ระบบ A ไม่ต้องรู้ด้วยซ้ำว่ามีระบบ C อยู่ โดยเราเลือกใช้เป็น Kafka เพราะสามารถทำ Scaling ได้ดี ตัวเลือกอื่น ๆ ก็จะเป็น Message Queue ของ Provider เอง แต่จากที่ลองใช้มายัง Tuning ให้ได้ความเร็วที่ต้องการในส่วนของ Realtime Application ได้ไม่เท่า Kafka แต่ถ้าไม่ได้ต้องการความเร็วมาก ๆ การใช้ของ Cloud Provider เลยก็จะลดภาระ Maintenance ไปได้เยอะมาก เพราะว่าการจะ Maintain Kafka ดี ๆ นี่ต้องเข้าใจลึกมาก ๆ และตัว Confluent เองก็ราคาแพงสุดใน Message Queue ที่ดูมาละ ถ้าจะยกตัวอย่าง Use case ที่โรงพยาบาลอาจจะนำเอา tool นี้ไปใช้เป็นประโยชน์ได้ก็คือการแจ้งเตือนผล Lab หรือ Imaging จาก Legacy system โดยอาจใช้ Debezium ในการต่อกับ Database เพื่อเอา Change เข้า Kafka เป็นต้น
Continuous Integration: ใช้เป็น GitHub Actions เพราะว่า Community Support เยอะมาก ๆ ในช่วงหลัง ๆ อย่างเช่น Nx ที่เราใช้อยู่ก็มีออก Tool ต่าง ๆ บน Github Actions ออกมาช่วยให้การพัฒนา CI สะดวก และ optimize ได้ง่ายขึ้น และข้อสำคัญคือทุกคนในทีมสามารถเข้ามาช่วยพัฒนา CI กันได้ อาจจะเพราะทั้ง Syntax สามารถเริ่มต้นได้ง่ายกว่าเจ้าอื่น ๆ อย่าง Jenkins หรือ Azure Pipeline
Continuous Delivery: ใช้เป็น ArgoCD เพราะว่า Application ทั้งหมดอยู่บน Kubernetes และตัวนี้เป็น Kubernetes Native การจัดการ Application บน Kubernetes ก็จะสะดวกกว่าตัวอื่น ๆ เช่น Jenkins เป็นต้น และส่วนสำคัญก็คือรองรับการทำงานแบบ GitOps จะเห็นว่าเราใช้ GitOps มาตั้งแต่ Infrastructure เลย อีกตัวที่สามารถทำแบบนี้ได้เช่นกันก็จะเป็น Flux แต่เลือกเป็น ArgoCD เพราะการ On-Boarding คนใหม่ ๆ ก็จะสะดวกกว่ามี GUI ให้อธิบาย (ปล. ไม่ได้ตาม Flux v2 นะ)
Logging, Tracing and Monitoring: ปัจจุบันใช้เป็น Elastic Stack เพราะว่ามี Application ที่ใช้ประโยชน์จาก Elasticsearch อยู่ เลยพยายามจำกัด Technology ไม่ให้เยอะเกินไปตามขนาดของบริษัททั้งในมุมของค่าใช้จ่าย และการดูแลระบบ ซึ่ง Elasticsearch ขึ้นชื่อเรื่องการจัดการ Log สามารถตั้งค่าได้ Log Retension Policy ได้สะดวก ไม่ต้องไปทำระบบเอง มี Agent ให้ไปติดตั้งหลายจุดทั้งใน Infrastructure, Kubernetes Cluster และอีกมากมาย หลัง ๆ การ Integrate Agent กับ Elasticsearch ก็ทำได้สะดวกขึ้นมาก ในส่วนของ Tracing เราก็ใช้ lib ของ elasticsearch ที่ช่วยจัดการเรื่อง trace id ให้ และใช้คู่กับ APM Agent ในการส่ง Metrics เข้าไปยัง Elasticsearch ซึ่งถ้าความหลากหลายของ Language ยังไม่มาก ใช้วิธีนี้ก็สะดวกดี อย่างไรก็ตามเราจะลดการใช้ Elasticsearch ใน Application และไปใช้ Datadog ที่ระบบในการ Tracing ให้ข้อมูลที่ลึกกว่ามาก ช่วยให้แก้ปัญหาได้เร็วกว่าจริง ๆ แต่ถ้าใครมี microservice ที่มีหลากหลายภาษา ต้องการ Align practice ในการทำ Monitoring และ Tracing อาจจะลองใช้ Service Mesh ในการจัดการดูได้
Metrics: นอกจากเรื่องการเอาไปใช้ในการหา Root Cause แจ้งเตือนก่อนเกิดปัญหาด้วย Elastic Stack แล้ว จะมีใช้งาน Promotheus เพื่อใช้สำหรับทำ Horizontal Scale บางกรณีอีกด้วย
Workflow Orchestration: ที่เราต้องมีตัว Workflow Orchestration เพราะมีทั้ง batch job และ sequence pipeline สำหรับ ETL ด้วย สำหรับ Tool นี้เราเลือกใช้เป็น Argo Workflow เพราะการจัดการเรื่อง Workflow สามารถทำได้ผ่าน Platform เลยโดยการเขียน YAML ในขณะที่อาจจะคุ้น ๆ กันอย่าง Airflow การกำหนด sequence pipeline จะต้องทำบนตัวโปรแกรมอีกที และเราใช้ ArgoCD อยู่แล้วด้วย การใช้ GUI ของ Argo ก็ง่ายดี เช่นเคยตัว Workflow ตัวอื่นที่แนะนำก็ของ Cloud Provider เลยไม่ต้อง maintain เองด้วย
Testing
Unit & Integration Test: เราใช้เป็น Jest ตัวนี้ก็ใช้กันแพร่หลาย และสามารถ integrate กับ Nx และ Nx Support โดยตรง
E2E Test: ตัวเลือกของ E2E Test มีค่อนข้างเยอะเช่น Robot Framework (python), Katalon (Java & Groovy), Test Project (No Language), Cypress (Javascript/Typescript), Playwright (Javascript/Typescript) การเลือกใช้อย่างแรกก็ดูที่ตามความถนัดของภาษาที่ใช้ของ QA และดูว่า Platform ที่ต้องการจะ Test มีอะไรบ้าง รองรับ Use case ที่จะใช้ไหมเช่นการเปิด new tab, การจัดการ print pop-up เป็นต้น แต่ตัวที่เราเลือกใช้จะเป็น Cypress เพราะว่าเป็น tool ที่ integrate กับ Nx โดย Nx support โดยตรง ซึ่ง QA ก็จะทำงานอยู่บน MonoRepo เดียวกับที่ Software Engineer ใช้ การ Test ด้วย Nx ช่วยให้เราสามารถแบ่ง Test ออกตาม Micro Frontend ที่มีการเปลี่ยนแปลใน Front-end นั้น ๆ ได้ รวมถึงสามารถแบ่ง Project เพื่อทำ Full Regress Test ได้ด้วย
Security
ส่วนนี้ขอเขียนเป็น Concept เพื่อลองไปเลือกใช้กันดู
Static Application Security Testing: จะเป็นการ check security ตั้งแต่ coding เลย ดังนั้น tool ที่จะนำมาใช้ก็ต้องเลือกตามภาษาที่ใช้ หลัก ๆ ที่ส่วนใหญ่ที่ tool นี้จะเข้ามาช่วยก็เรื่อง OWASP Top 10 การ Test รูปแบบนี้จะเรียกว่า White Box เพราะว่าทำใน layer ที่รู้ระบบภายใน รู้โครงสร้างด้านใน การใช้ Tool นี้จะช่วยให้ Software Engineer มีความตื่นรู้ (Awareness) ในเรื่อง Security ตั้งแต่ตอน code เลย มี Tool ที่สามารถทำได้เยอะมาก ถ้าตัวที่อาจจะเคยได้ยินชื่อกัน ตัวอย่างเช่น Sonarcube, Synk, Veracode เป็นต้น
Dynamic Application Security Testing: การทำ test รูปแบบนี้จะเรียกว่า Black Box เพราะว่าจะเป็นการทดสอบระบบผ่านตัว Application โดยที่ Tool ไม่รู้โครงสร้างภายในของระบบเลย จะทำการตรวจสอบด้วยการ Scan ตามช่องโหว่ที่เจอบ่อย ๆ หลาย ๆ tool ก็จะทำการ update ให้ช่องโหว่ใหม่ ๆ ให้อัตโนมัติ บาง tool อาจจะต้องเติม extension กันเอง การเลือกใช้ก็ขึ้นอยู่กับ Platform ที่พัฒนาว่าเป็น Web, Desktop App หรือ Mobile App
Interactive Application Security Testing: การทำ test อย่างสุดท้ายที่จะแนะนำเรียกว่า Grey Box โดยจะเป็นการ Test ผ่าน Application โดยที่เรารู้ Workflow การทำงานของ Application แต่ไม่รู้โครงสร้างทั้งหมดของ Application การจะทำ IAST จะใช้ Workload เยอะกว่าประเภทอื่นที่กล่าวมา การทำให้มีประสิทธิภาพต้องอาศัยผู้เชี่ยวชาญระดับหนึ่ง tools ที่น่าจะพอคุ้นหูกันบ้างก็จะเป็น Acunetix หรือ BurpSuite Enterprise แต่ถ้าไม่ได้มีคนที่เชี่ยวชาญการจ้าง Outsource ที่เชี่ยวชาญด้านนี้เลยก็เป็นทางเลือกที่หลาย ๆ บริษัทเลือกกัน
ส่วนของ Security ยังมี tool ให้ใช้ได้อีกหลาย stage ของ Application ใครสนใจก็ลองศึกษาเรื่อง DevSecOps เพิ่มเติมได้
Data Analytics
Language: ภาษาที่ใช้หลักในทีมจะใช้เป็น python เพราะว่าเป็นภาษาที่ใช้ง่าย มี library ให้ใช้เยอะมาก ๆ ที่ช่วย support data analytics และอีกผลหลักก็คือต้องการความสะดวกในการทำ model ออกเป็น Model as a Service จึงเลือกใช้ Python ในขณะที่หากใช้ R หรือ Octave ก็จะค่อนข้างยากในการทำออกมาเป็น Service
Business Intelligence: ตัวเลือก BI ในตลาดตอนนี้หลัก ๆ ก็จะมีให้เลือก 3 เจ้า Tableau, Power BI และ Looker โดยตัวที่เราพิจารณาหลัก ๆ จะเป็นระหว่าง Tableau และ Looker ความสามารถของทั้ง 2 ตัวมีความใกล้เคียงกันมาก ๆ แต่ส่วนที่ต่างกันมาก ๆ คือเรื่องแนวคิดการจัดการ Tableau จะใช้มี Built-in drag & drop ให้ใช้ สามารถ prepare หรือทำ last mile data โดยภาษาของ Tableau เอง ข้อดีอีกอย่างของ Tableau จะเป็นเรื่องการ drill down ใน dashboard เพื่อหา insightในขณะที่ Looker จะเน้น experience การใช้ SQL และสามารถทำงานบน Git ได้ และเน้นไปที่ Dashboard เป็นหลักไม่ได้เน้นการทำ Analytics แต่สามารถทำ Machine Learning Model ได้บน BigQueryML ในเรื่องของราคา Tableau คิดราคาตาม User สำหรับ Creator จะอยู่ที่ $70 ต่อคน ในขณะที่ Looker จะเป็น Monthly flat rate ที่ $5000 ดังนั้นในช่วงเริ่มต้น Tableau จึงคุ้มค่ากว่ามาก แต่ถ้าขนาดทีมเริ่ม Scale และมี Project ที่ต้องดูแลจำนวนมาก การทำ Practice อยู่บน Git จะสามารถทำการควบคุมและทำงานเป็นทีมได้ดีกว่า ตอนนี้ทีมเราไม่ได้ใหญ่มากจึงเลือกใช้ Tableau ในจังหวะที่เหมาะสมก็มอง Looker เป็น option ในอนาคต
Data Warehouse: ตัว Main หลักที่จะใช้จะเป็น BigQuery เพราะว่ามี Pricing model ที่เป็น Multi Tenant ทำให้มีราคาถูกกว่า Platform อื่น ๆ และยังสามารถใช้ SQL ในการทำงานได้ ในขณะที่ตัว Cloud หลักที่เราใช้อย่าง Azure จะมี Azure Synpase ที่ราคาเริ่มต้นของ Dataware ราคาเริ่มต้นสูงกว่า $1,000 เราจึงเลือกใช้ BigQuery เป็น Tool หลัก นอกจากนี้ตัว BigQuery ยังสามารถเชื่อมต่อกับ FHIR Datastore ของ Google เองได้อีกด้วย ทำให้สะดวกต่อการทำ data analytics, machine learning model บน Healthcare Data Lake ซึ่งตัว FHIR ของ Google น่าจะ performance ดีที่สุดในตลาด ณ ตอนนี้ (เรื่อง FHIR จะอยู่ท้ายของบทความนะ)
Model as a Service: เมื่อก่อนจะใช้เป็น Flask ซึ่งสะดวกง่ายต่อการทำ model as a service มาก ๆ เข้าใจง่ายสำหรับ Data Scientist ที่ไม่ได้ถนัดในการพัฒนา API มากนัก แต่มีแนวคิดให้การทำ model as a service ได้มาตรฐานการพัฒนาเท่ากับ Software หลัก จึงลอง Explore แล้วมาเจอ FastAPI ที่มี pattern การเขียนที่แยกส่วน code ของ interface, model, logic เป็นแนวทางที่ง่ายไม่ซับซ้อนเท่า Django แต่ก็ไม่ได้เล็กมาก ๆ เท่า Flask ที่การทำเรื่อง security practice ไม่ได้มี guildeline มาให้ครบเท่า FastAPI และไม่ได้ซับซ้อนจน Data Scientist ที่ทำ model จะใช้เวลาเรียนรู้นาน ตอนนี้จึงเลือกใช้ FastAPI เป็นหลัก
Machine Learning: เนื่องจากใช้ python เป็นภาษาหลัก ตัว Machine Learning Model ก็จะใช้ package จาก python นี้แหละไล่ตั้งแต่ basic library ไม่ว่าจะเป็น pandas, numpy, scikitlearn, PyTorch, PyThaiNLP เป็นต้น
Operation Research: นอกจากที่เราจะทำ Model ที่เป็น Predictive model แล้วเรายังทำ Prescriptive Model ด้วย ยกตัวอย่างเช่นการจัดการตารางเวรของแพทย์ และพยาบาล หรือการจัดการ Case Refer in/out เพื่อให้การเบิกจ่ายของโรงพยาบาลสูงสุด ก็มีทดลองวิจัยมาตั้งแต่การใช้ Heuristic Algorithm การใช้ Mix Integer Programming (MIP) ซึ่งก็ทำอยู่บน python เช่นกัน ตัวอย่าง package ที่จะใช้สำหรับ MIP ก็จะเป็น pulp เป็นต้น
Health Tech
ส่วนนี้คนนอกวงการ Health Tech อาจจะเข้าใจยากสักหน่อย เทคโนโลยีที่เรานำของที่อยู่ในตลาดมาใช้หลัก ๆ จะเป็น FHIR Server (เดี๋ยวจะอธิบายสั้น ๆ ว่าคืออะไร) ส่วน Terminology server ปัจจุบันยัง custom เอง แต่ก็เริ่มทดสอบตัวที่ใช้กันเยอะ ๆ อย่าง Ontoserver เป็นต้น
FHIR: ปัจจุบันใช้เป็น Managed service ของ Google Cloud ไปเลย ลดภาระในการจัดการ sensitive data และการจัดการ Access Control นอกจากนี้ยังสามารถเชื่อมต่อกับ Big Query ให้สามารถทำ Data Analytics บน Standard data format ได้เลย แถมไม่ต้องจัดการ performance เองอีกด้วย ทำให้สามารถใช้งานจริงบน production ได้อย่างรวดเร็ว
Disclaimer ซะหน่อยว่าไม่ได้ Sponsor จากทั้ง Azure และ Google นะครับ
ก่อนจากกัน
เอาตรง ๆ จุดประสงค์ของการแชร์ Tech stack นี้ก็เผื่อมีคนที่มี Skill ด้านที่ตรงกัน หรืออยากหาโอกาสในการมาเรียนรู้สิ่งใหม่ ๆ มาร่วมทำงานกับเรา อย่างไรก็ตามความท้าทายหลัก ๆ ไม่ใช่เรื่อง Tech Stack แต่เป็นการพัฒนาให้ Software มีคุณภาพ มีโครงสร้างที่สามารถขยายได้ แบ่งทีมกันทำงาน และปลอดภัย ใครสนใจร่วมพัฒนา Complex Software System ก็กดลิ้งด้านล่างดูรายละเอียดแล้วสมัครกันเข้ามาได้เลย
Medium : H LAB Medium
Interested in working with us?
Please Visit : หางาน สมัครงาน ที่ H LAB | Blognone Jobs or email us @ recruit@hlabconsulting.com