รูปแบบข้อมูล PHR

ระบบจะจัดเก็บข้อมูลเวชระเบียนส่วนบุคคล (PHR) ในรูปแบบ HL7 FHIR

PHR รองรับ Fast Health Interoperable Resources (FHIR) เวอร์ชันต่อไปนี้

ประเภทแหล่งข้อมูลทางการแพทย์

FHIR ประกอบด้วยชุดคอมโพเนนต์แบบโมดูลที่เรียกว่าทรัพยากร ชุดทรัพยากร FHIR และหมวดหมู่ที่เกี่ยวข้องที่รองรับจะอิงตามส่วนสรุปผู้ป่วยระหว่างประเทศโดยคร่าวๆ

ทรัพยากรเหล่านี้จะเชื่อมโยงกับหมวดหมู่ข้อมูลใน Health Connect ซึ่งเรียกว่าประเภททรัพยากรทางการแพทย์ใน API ระบบจะแมปแหล่งข้อมูลการสังเกตการณ์ตามเนื้อหา เช่น ชื่อและรหัสตัวระบุการสังเกตการณ์เชิงตรรกะ (LOINC) และหมวดหมู่ FHIR

ระบบจะไม่เขียนข้อมูลการสังเกตการณ์ที่ไม่ได้อยู่ในหมวดหมู่เหล่านี้ลงใน Health Connect

ตารางที่ 1: ประเภททรัพยากรทางการแพทย์ของ Health Connect
ประเภททรัพยากรทางการแพทย์ของ Health Connect ทรัพยากร FHIR
อาการแพ้ AllergyIntolerance
ภาวะทางการแพทย์ เงื่อนไข
ห้องปฏิบัติการ

การสังเกต

  • laboratory หมวดหมู่ FHIR
ข้อมูลยา Medication, MedicationRequest, MedicationStatement
รายละเอียดส่วนตัว ผู้ป่วย
รายละเอียดผู้ประกอบวิชาชีพทางการแพทย์ Practitioner, PractitionerRole
การตั้งครรภ์

การสังเกต

  • รหัส LOINC การตั้งครรภ์
การทำหัตถการ ขั้นตอน
ภาวะสังคม

การสังเกต

  • รหัส LOINC ของภาวะสังคม
  • social-history หมวดหมู่ FHIR
วัคซีน วัคซีนและภูมิคุ้มกัน
การพบแพทย์ การพบปะ สถานที่ตั้ง องค์กร
สัญญาณชีพ

การสังเกต

  • รหัส LOINC ของสัญญาณชีพ
  • vital-signs หมวดหมู่ FHIR

แหล่งข้อมูลสำหรับผู้ป่วย

ปัจจุบัน Health Connect มีไว้เพื่อจัดเก็บข้อมูล PHR ของบุคคลธรรมดาเพียงรายเดียวเท่านั้น ดังนั้นทรัพยากร FHIR ทั้งหมดที่เขียนขึ้นควรเป็นของบุคคลเดียวกัน

การที่ทรัพยากรผู้ป่วย FHIR หลายรายการอยู่ในระบบสำหรับบุคคลธรรมดาเพียงคนเดียวนั้นไม่ใช่เรื่องผิดปกติ เราขอแนะนำให้แอปปรับยอดข้อมูลและเขียนแหล่งข้อมูลผู้ป่วยรายการเดียวลงใน Health Connect อย่างไรก็ตาม ระบบจะไม่บังคับใช้รูปแบบนี้เพื่อรองรับโครงสร้างองค์กรที่แตกต่างกันที่อาจมีอยู่

การตรวจสอบข้อมูล

PHR API จะยอมรับทรัพยากร FHIR ที่ถูกต้องจากเวอร์ชันที่รองรับ และ Health Connect จะดำเนินการตรวจสอบบางอย่างเพื่อยืนยันว่ามีการปฏิบัติตามข้อกำหนด FHIR สำหรับเวอร์ชันที่รองรับแต่ละเวอร์ชัน

การตรวจสอบความถูกต้องที่ทําเครื่องหมายเป็นเร็วๆ นี้ยังไม่บังคับใช้ แต่จะใช้ได้ในรุ่นที่จะออกในอนาคต เราขอแนะนำให้พัฒนาตามการตรวจสอบการทํางานทั้งหมดที่ระบุไว้เพื่อรักษาความเข้ากันได้กับรุ่นในอนาคต

ตารางที่ 2: การตรวจสอบข้อมูล FHIR ของ Health Connect
ระดับ การตรวจสอบความถูกต้อง
JSON ที่ถูกต้อง ข้อมูลเป็นไปตามรูปแบบ JSON
FHIR ที่รองรับ

ระบบรองรับเวอร์ชัน FHIR ที่ประกาศโดยแอปพลิเคชันการเขียน Health Connect รองรับ FHIR เวอร์ชันต่อไปนี้

  • 4.0.1
  • 4.3.0
FHIR ที่รองรับ

ระบบรองรับประเภททรัพยากร FHIR ที่บันทึกไว้ในอินสแตนซ์ทรัพยากร Health Connect รองรับประเภททรัพยากร FHIR ต่อไปนี้

  • AllergyIntolerance
  • เงื่อนไข
  • แพ็กเกจใกล้ชิดกับโลมา
  • วัคซีนและภูมิคุ้มกัน
  • ตำแหน่ง
  • ยา
  • MedicationRequest
  • MedicationStatement
  • การสังเกต
  • องค์กร
  • ผู้ป่วย
  • แพทย์
  • PractitionerRole
  • ขั้นตอน
รหัสทรัพยากรที่ไม่ซ้ำกัน ทรัพยากรมีช่องรหัสซึ่งมีค่าที่เป็นไปตามข้อกําหนดของนิพจน์ทั่วไป
รหัสทรัพยากรที่ไม่ซ้ำกัน ทรัพยากรไม่ได้แชร์รหัสกับทรัพยากร FHIR อื่นที่มีประเภททรัพยากรเดียวกันจาก MedicalDataSource เดียวกัน
กฎทางธุรกิจ ไม่รวมทรัพยากร FHIR ที่มีอยู่ ทรัพยากรที่รวมอยู่คือทรัพยากร FHIR ที่ฝังอยู่ภายในทรัพยากร "หลัก" ทรัพยากรย่อยจะใช้เมื่อทรัพยากรหลักต้องอ้างอิงทรัพยากรอื่น แต่ระบบมีข้อมูลไม่เพียงพอที่จะสร้างทรัพยากรนี้ขึ้นมาเป็นทรัพยากรแบบสแตนด์อโลนที่ดำรงอยู่อย่างอิสระ
FHIR พื้นฐานที่ถูกต้อง ช่องระดับบนสุดใน FHIR JSON อยู่ในข้อกำหนด FHIR สำหรับประเภททรัพยากรที่ระบุ
FHIR พื้นฐานที่ถูกต้อง ช่องระดับบนสุดไม่มีค่า Null ของ JSON
FHIR พื้นฐานที่ถูกต้อง มีช่องที่ต้องกรอกระดับบนสุดครบถ้วน
FHIR พื้นฐานที่ถูกต้อง ช่องระดับบนสุดที่กําหนดเป็นองค์ประกอบที่ซ้ำกันใน FHIR จะมีประเภทข้อมูล JSON array
FHIR พื้นฐานที่ถูกต้อง ช่องระดับบนสุด (รวมถึงองค์ประกอบภายใน array ของ JSON) ที่กําหนดเป็นประเภทที่ซับซ้อนใน FHIR จะมีประเภทข้อมูล object ของ JSON
FHIR พื้นฐานที่ถูกต้อง ช่องระดับบนสุด (รวมถึงองค์ประกอบภายใน array ของ JSON) ที่กําหนดเป็นประเภทพื้นฐานใน FHIR ต้องเป็นประเภทข้อมูล JSON ที่ถูกต้อง
ประเภทข้อมูล FHIR ประเภทข้อมูล JSON
integer, unsignedInt, positiveInt, decimal ตัวเลข
บูลีน บูลีน
instant, time, date, dateTime, string, code, markdown, id uri, url, oid, uuid, canonical, integer64, base64Binary ตัวเลข
เร็วๆ นี้
FHIR พื้นฐานที่ถูกต้อง ฟิลด์ระดับบนสุดที่กําหนดเป็นประเภทพื้นฐานใน FHIR ต้องเป็นไปตามข้อกําหนดของนิพจน์ทั่วไป เร็วๆ นี้
FHIR พื้นฐานที่ถูกต้อง ส่วนขยายสำหรับประเภทพื้นฐานมีอยู่ในสเปค FHIR และมีประเภทข้อมูล JSON object
FHIR พื้นฐานที่ถูกต้อง ระบบจะบันทึกช่องตัวเลือก (fieldname[x]) ไม่เกิน 1 ช่อง เช่น effectiveDateTime และ effectivePeriod ต้องไม่ปรากฏในอินสแตนซ์แหล่งข้อมูลเดียวกัน
FHIR พื้นฐานที่ถูกต้อง ประเภทข้อมูลที่ซับซ้อนประกอบด้วยช่องและประเภทข้อมูลที่ตรงกับข้อกำหนด FHIR เร็วๆ นี้
FHIR พื้นฐานที่ถูกต้อง องค์ประกอบแบ็กโบนน์ (และองค์ประกอบภายในประเภทที่ซับซ้อน) มีช่องและประเภทข้อมูลที่ตรงกับข้อกำหนด FHIR เร็วๆ นี้
FHIR พื้นฐานที่ถูกต้อง องค์ประกอบส่วนขยาย ช่อง value[x] เป็นประเภทที่ถูกต้องและมีเนื้อหาตามประเภทข้อมูลนั้น องค์ประกอบส่วนขยายสามารถรวมอยู่ในทรัพยากรใดก็ได้เพื่อแสดงข้อมูลเพิ่มเติมที่ไม่ได้อยู่ในข้อกำหนดพื้นฐาน โดยจะมีช่อง url ที่ลิงก์กับคำจำกัดความของส่วนขยาย และช่อง value[x] ที่มีค่าส่วนขยาย value[x] ต้องมาจากรายการประเภทข้อมูลที่ยอมรับ เร็วๆ นี้

ข้อมูล FHIR ที่เปลี่ยนรูปแบบ

แอปบางแอปจะเปลี่ยนรูปแบบข้อมูล FHIR เพื่อให้เป็นไปตามข้อกำหนดของตนเอง เช่น

  • การผสานข้อมูลจากแหล่งที่มาต่างๆ (โดยทั่วไปคือ FHIR API)
  • การแมปรหัสกับคำศัพท์ทั่วโลก (เช่น SNOMED, LOINC, ICD) และการทำให้หน่วยเป็นมาตรฐาน
  • การรวมและกรองข้อมูลซ้ำ
  • การแก้ไขการจัดรูปแบบหรือปัญหาอื่นๆ ด้านคุณภาพของข้อมูล
  • การกรองระเบียนตามกฎทางธุรกิจเฉพาะแอป

ข้อมูล FHIR ที่ไม่ได้เปลี่ยนรูปแบบและเปลี่ยนรูปแบบแล้วสามารถเขียนลงใน Health Connect ได้ ตราบใดที่ข้อมูลดังกล่าวเป็นไปตามข้อกำหนด FHIR R4 เราขอแนะนำให้คุณเขียนข้อมูลที่เปลี่ยนรูปแบบเมื่อเป็นไปได้ แต่โปรดคำนึงถึงข้อควรพิจารณาต่อไปนี้

  • แอปที่มี Use Case แบบแคบอาจกรองระเบียนจำนวนมากออก ซึ่งแอปอื่นๆ ในระบบนิเวศอาจสร้างคุณค่าให้แก่ผู้ใช้ได้ ในกรณีเช่นนี้ คุณอาจต้องเขียน FHIR ที่ไม่ได้เปลี่ยนรูปแบบซึ่งสมบูรณ์กว่า อย่างไรก็ตาม โปรดแจ้งให้ผู้ใช้ทราบว่ามีการแชร์ชุดข้อมูลขนาดใหญ่นี้
  • หากผสานข้อมูลที่มาจากแหล่งที่มาต่างๆ คุณจะเขียนข้อมูลลงใน MedicalDataSource รายการเดียวใน Health Connect ได้ นอกจากนี้ คุณยังต้องกําหนดรหัสใหม่ให้กับทรัพยากรแต่ละรายการเพื่อหลีกเลี่ยงการทับซ้อน และอัปเดตการอ้างอิงทรัพยากรเพื่อชี้ไปยังรหัสใหม่
  • การผสานข้อมูลจากแหล่งที่มาหลายแห่งลงใน MedicalDataSource รายการเดียวอาจทำให้แหล่งที่มาของข้อมูลไม่ชัดเจน เนื่องจากความเข้าใจแหล่งที่มาของข้อมูลมักเป็นประโยชน์ต่อผู้ใช้ข้อมูล เราจึงขอแนะนำให้ป้อนข้อมูลในช่อง meta.source สำหรับแต่ละแหล่งข้อมูลด้วยแหล่งที่มาเดิมของระเบียน (โดยทั่วไปคือ URL ฐาน FHIR)