تصدير مفكرة المثانة إلى Epic وCerner وغيرهما من أنظمة السجلات الطبية الإلكترونية

يُصدِّر Bladder Diaries مفكرة المريض في صورة ملفين قياسيين: حزمة FHIR R4 (.fhir.json) للسجلات الإلكترونية الحديثة التي تستوعب FHIR، وحزمة HL7 C-CDA R2.1 CCD (.ccd.xml) للأنظمة القديمة وللمراسلة عبر Direct Secure Messaging. يُبنى الملفان معاً داخل المتصفح، ويُنزَّلان محلياً، ثم يُرفقان بالسجل عبر المدخل القياسي للسجل المُستقبِل. لا تعبر أي بيانات للمريض خوادم bladderdiaries.com؛ بل تستبدل أداة chart-matching لدى المُستقبِل العنصرَ النائب لمورد Patient الاصطناعي عند الاستيعاب.

لقد أتممتم للتو مفكرة مدتها 3 أيام مع أحد المرضى. أعادت الحاسبة: MVV (الحجم الأقصى المُفرغ) 320 mL، و AVV (متوسط الحجم المُفرغ) 145 mL، و NPi (مؤشر البوال الليلي) 32%، و 24hVV (حجم البول خلال 24 ساعة) 2.1 L، و FVC (مخطط التكرار والحجم) بتكرار قدره 9 مرات تبول في 24 ساعة. يبقى السؤال السؤال الميكانيكي: كيف تصل هذه الأرقام إلى السجل في صورة يقدر مُرمِّزكم وممرضتكم وعيادة المتابعة التالية على قراءتها؟ يغطي هذا الدليل الصيغتين، وموضع كلٍّ منهما في Epic و Cerner / Oracle Health و Athena Health و Prompt Health (عبر Kno2) وفي السجل الإلكتروني القديم، فضلاً عن صورة عقد الـ chart-matching من جانب المُستقبِل.

صيغتا الملف: FHIR R4 Bundle مقابل HL7 C-CDA R2.1 CCD

المعياران في كتالوج استيراد السجلات هما FHIR (Fast Healthcare Interoperability Resources) و C-CDA (Consolidated Clinical Document Architecture). وكلاهما معياران من HL7، ويحملان البيانات نفسها للمفكرة في صيغتي نقل مختلفتين. ويُصدِر Bladder Diaries كلتيهما لأن منظومة السجلات الإلكترونية ثنائية اللغة: تستوعب المنظومات الحديثة FHIR بشكل أصيل، وتستوعب المنظومات العيادية القديمة C-CDA، وتشترط التشريعات الفيدرالية الأمريكية (21st Century Cures Act و ONC Cures Act Final Rule) منذ عام 2023 أن تدعم تقنية السجل الإلكتروني المعتمدة FHIR R4، مع الإبقاء على C-CDA R2.1 منحدراً للأنظمة القديمة.

FHIR R4 Bundle: المسار الحديث

أُصدر FHIR R4 في أكتوبر 2019، وهو معيار JSON موجه نحو الموارد تستوعبه المجموعة الحديثة من السجلات الإلكترونية. ويُسلَّم الملف المُصدَّر على شكل Bundle من النوع type: "collection" يحتوي ما يلي:

• مورد Patient نائب واحد يحمل القيمة الحارسة REPLACE_WITH_MRN في Patient.identifier. ويملأ المُستقبِل رقم السجل الطبي الحقيقي عند الاستيعاب.
• N من موارد Observation على مستوى الحدث: واحدة لكل تبول، وواحدة لكل تناول للسوائل، وواحدة لكل تقييم إلحاح حين يكون موثقاً، وواحدة لكل حدث تسرب. فيرى المُستقبِل الجدول الزمني الخام.
• 5 من موارد Observation على مستوى المقاييس المحسوبة لـ MVV و AVV و NPi و 24hVV و FVC، يحمل كلٌّ منها ترميزاً هجيناً يجمع LOINC مع ترميز CodeSystem مخصص لـ Bladder Diaries (وفق Phase 8 D-12). فيحصل المُستقبِل على ترميز قياسي وترميز دقيق معاً.
• مورد DiagnosticReport واحد يلخص المقاييس، ويُضمَّن فيه ملف الـ PDF بصيغة base64 ضمن presentedForm[0].data. ويرافق بذلك مصدرٌ مقروء للإنسان البيانات المهيكلة في كل الأحوال.

تجتاز الحزمة التحقق مقابل مخطط HL7 R4 ومقابل ملف تعريف US Core 6.1.0 Implementation Guide. ويرى المُستقبِلون الذين يُعرِّفون مقابل US Core (Epic، Cerner / Oracle Health، Athena، Allscripts / Veradigm) الحقولَ المتوقعة: Patient.identifier و Observation.code و Observation.value[x] و Observation.effectiveDateTime و DiagnosticReport. أما المُستقبِلون الذين لا يُعرِّفون مقابل US Core فيحصلون مع ذلك على شكل R4 الأساسي، وهو كافٍ للاستيعاب.

HL7 C-CDA R2.1 CCD: منحدر الأنظمة القديمة

أُصدر C-CDA R2.1 في يوليو 2015، وهو المعيار الوثائقي القائم على XML الذي تستوعبه المجموعة العيادية القديمة من السجلات الإلكترونية ومنفذ Direct Secure Messaging. ويُسلَّم التصدير على شكل ClinicalDocument يتضمن:

• ترويسة US Realm Header (CONF:1198-*) التي تغطي العنصر النائب Patient، ومنظمة الـ custodian، ومؤلف الوثيقة، وبنية CDA القياسية.
• جسماً (body) يحتوي الأقسام الستة الإلزامية في CCD (الحساسيات، الأدوية، المشكلات، الإجراءات، النتائج، السيرة الاجتماعية)، مع وضع nullFlavor="NI" على الأقسام التي لا تملؤها المفكرة.
• منظماً (Results) يحمل المقاييس المحسوبة الخمسة نفسها، مع تصريح مزدوج لمعرّف القالب Result Observation V3 (2.16.840.1.113883.10.20.22.4.2، امتداد 2015-08-01) في كل عنصر <observation>.
• عنصر observationMedia يحمل تقرير الـ PDF مُضمَّناً بصيغة base64 داخل النص، دون الحاجة إلى مرفق منفصل.

ويجتاز الـ CDA التحقق مقابل مخطط HL7 SDWG C-CDA R2.1 schematron (الذي أُغلِق في Phase 11 Plan 11-01). ويُعدّ مسار C-CDA الاختيار الصحيح حين يسبق السجلُ الإلكتروني المُستقبِل دورةَ امتثال 21st Century Cures Act، أو حين تتوسط Direct Secure Messaging سير العمل، أو حين يكون فريق IT لدى المُستقبِل قد عطّل مدخل FHIR.

أيهما أختار؟

| السجل الإلكتروني المُستقبِل | الصيغة | سطح المدخل | | --------------------------- | ---------- | ------------------------------------------------------------------------- | | Epic | FHIR R4 | تطبيق SMART on FHIR، FHIR Inbox، مرفق سجل في زيارة اعتيادية | | Cerner / Oracle Health | FHIR R4 | مدخل FHIR R4، Bridges، Code App Gallery | | Athena Health | FHIR R4 | مدخل More Disruption Please (MDP)؛ الارتداد إلى CCD حين يكون MDP مُعطّلاً | | Prompt Health | أيٌّ منهما | شراكة Kno2: يقبل المُطبِّع لدى المُستقبِل كلتا الصيغتين | | Allscripts / Veradigm | FHIR R4 | استيعاب dbMotion / TouchWorks | | NextGen | C-CDA | مدخل CCD؛ خارطة طريق FHIR لم تُسلَّم بعد لجميع الإصدارات | | eClinicalWorks | C-CDA | مدخل CCD | | Greenway / Intergy | C-CDA | مدخل CCD | | الأنظمة القديمة المتفرقة | C-CDA | Direct Secure Messaging (DSM)، التسليم عبر HIE إلى صندوق الوارد |

قاعدة القرار: أرسلوا FHIR R4 إذا علمتم أن المُستقبِل يدعم FHIR. وأرسلوا C-CDA إذا كان غير معلوم لديكم، أو إذا كان المُستقبِل واقعاً صراحةً على منحدر الأنظمة القديمة. ويُصدر Bladder Diaries كلا الملفين من خرج الحاسبة نفسه، فيمكنكم الإبقاء على كليهما في متناول اليد واستخدام ما يقبله المُستقبِل فعلاً.

خطوة بخطوة: من ‎/entry‎ إلى السجل

يتألف سير العمل من طرف إلى طرف من أربع خطوات: تُنجَز الثلاث الأولى داخل متصفحكم على bladderdiaries.com، وتُنجَز الرابعة داخل السجل الإلكتروني المُستقبِل.

الخطوة 1: إدخال المفكرة في ‎/entry‎

افتحوا الحاسبة على bladderdiaries.com. أدخلوا مفكرة المريض في صورة عمليات تبول، وعمليات تناول للسوائل، وعلامات وقت النوم، و(إذا كانت موثقة) أحداث تسرب وتقييمات إلحاح. ويستغرق نموذج الإدخال على شاشة واحدة نحو 90 ثانية لمفكرة نموذجية مدتها 3 أيام. ويقود سنُّ المريض وعلامة التبول اللاإرادي عتبةَ NPi وفق الفئة العمرية، فضلاً عن تصنيف التحكم في التبول.

الخطوة 2: قراءة المقاييس في ‎/results‎

تُحوِّل الحاسبةُ المسارَ إلى /results بعد الإرسال. وتُظهر الصفحة MVV و AVV و NPi و 24hVV و FVC إضافةً إلى تصنيف IPC (Integrated Pelvic Care) 4Is (Fluid Imbalance و Storage Impairment و Voiding Impairment و Incontinence). ويُغذي هذا الإطار رباعي المحاور لغةَ السجل في ملاحظة الزيارة لاحقاً؛ راجعوا الركيزة المتعلقة بتفسير مفكرة المثانة للاطلاع على المنهج السريري الذي يقرن الأرقام بالتشخيص التفريقي.

الخطوة 3: الضغط على زر التصدير

يحمل شريط التصدير أعلى صفحة /results ثلاثة أزرار: PDF و FHIR Bundle و C-CDA CCD. اضغطوا على الصيغة التي يقبلها السجل المُستقبِل. يُبنى الملف داخل المتصفح (FHIR Bundle بصيغة JSON و CCD بصيغة XML)، ويصل إلى مجلد التنزيلات لديكم باسم محدد سلفاً: bladder-diary-YYYY-MM-DD.fhir.json أو bladder-diary-YYYY-MM-DD.ccd.xml. ولا يحدث أي رفع HTTPS إلى bladderdiaries.com؛ بل تُؤكد رسالة التنبيه: "تم التنزيل. ملاحظة: الملف مُخزَّن على جهازكم خارج هذه الحاسبة".

الخطوة 4: إرفاق الملف بالسجل في السجل الإلكتروني المُستقبِل

Epic عبر SMART on FHIR: إذا كانت منظمتكم قد طوّرت تطبيق SMART on FHIR موجَّهاً للمريض، يرفع المريضُ حزمةَ FHIR عبر MyChart. وإذا كان فريق IT قد فعَّل FHIR Inbox فأودعوا الملف هناك. وإن لم يتوفر أيٌّ من المسارين فأرفقوا حزمة FHIR بوصفها مرفقاً بالسجل في زيارة اعتيادية؛ يبقى الملف في السجل بوصفه ملفاً ثنائياً، ويمكن إعادة قراءة بياناته المهيكلة لاحقاً.

Cerner / Oracle Health: يَقبل مدخل FHIR R4 الملف عبر عملية R4/$import حين يُفعِّلها فريق IT. وتمر مؤسسات كثيرة عبر Bridges (طبقة قابلية التشغيل البيني لـ Oracle Health). ويُمثّل Code App Gallery مساراً ثالثاً، إذ يُعد سطح SMART on FHIR يُرفع الملف فيه بوصفه مورداً مرتبطاً بالمريض.

Athena Health: مدخل More Disruption Please (MDP) هو مسار FHIR R4. أودعوا حزمة FHIR عبر نقطة نهاية MDP. وإن كانت نسختكم من Athena تُتيح فقط مدخل CCD القديم فأرسلوا بدلاً من ذلك C-CDA CCD.

Prompt Health: تَقبل شراكة Kno2 كلتا الصيغتين. ويعمل Kno2 بوصفه مُطبِّعاً من جانب المُستقبِل يحوِّل FHIR أو CCD إلى الصيغة التي يتوقعها السجلُّ الإلكتروني في المراحل اللاحقة. وينطبق المسار نفسه على أي سجل ضمن شبكة Kno2.

السجل الإلكتروني القديم عبر Direct Secure Messaging (DSM): يتنقل ملف C-CDA CCD عبر DSM في صورة مرفق XML. ويُسلِّمه مقدم خدمة المعلومات الصحية (HISP) لدى المُستقبِل إلى صندوق الوارد لديه. ويُعدّ مسار DSM الاختيار الصحيح للعيادات التي لم تَتبنَّ FHIR بعد.

أما البديل القائم على البريد الإلكتروني العادي فلا يُنصح به. آثروا المدخل القياسي للسجل الإلكتروني المُستقبِل؛ ويبقى مسار البريد الإلكتروني سير عمل يدوياً يُلجأ إليه في آخر المطاف فقط.

عقد الخصوصية: عمل عميل محض، دون عبور بيانات صحية محمية

أهم خصائص خط أنابيب التصدير أنه لا ينقل بيانات المريض أبداً. فالملفان يُبنيان بالكامل داخل متصفحكم انطلاقاً من بيانات المفكرة التي أدخلها الطبيبُ في /entry. ولا تقيم المفكرة سوى داخل localStorage الخاص بالمتصفح: لا قاعدة بيانات على الخادم، ولا رفع HTTPS إلى bladderdiaries.com، ولا تحليلات لطرف ثالث على حمولة المفكرة.

السجلّ الإلكتروني المُستقبِل هو السلطةُ المعنية بـ chart-matching. ويحمل العنصرُ النائب لـ Patient القيمةَ REPLACE_WITH_MRN في Patient.identifier تحديداً ليتسنى للمُستقبِل تشغيل عملية المطابقة الخاصة به مقابل فضاء أسماء MRN المحلي. وتُحدِّد سياسة IT لدى المُستقبِل ما إذا كانت المطابقة آلية (عبر عملية R4/$import على مستوى النظام مع قاعدة ربط بالسجل) أم يدوية (يقوم موظفو الاستقبال بمطابقة الملف الوارد بالسجل). أما Bladder Diaries فلا يرى ولا يُخزِّن ولا ينقل أي معلومة تتعلق بالمطابقة.

ينبثق الوضع التنظيمي إزاء HIPAA / GDPR من هذا التصميم. ويبقى Bladder Diaries خارج محيط HIPAA Covered Entity وخارج محيط مراقب البيانات في GDPR لأنه لا يحتفظ بأي بيانات للمريض على خوادمه. فالمتصفح المحلي للطبيب يحتفظ بالمفكرة، ونظام ملفاته يحتفظ بالملف المُصدَّر، والسجل الإلكتروني المُستقبِل يحتفظ بالسجل. وكل حلقة منها سطح امتثال معروف لفريق IT المحلي ولاتفاقية الشريك التجاري (Business Associate Agreement) المحلية حيث تنطبق؛ أما حلقة bladderdiaries.com فهي فارغة بالتصميم.

وقد وُثِّق ذلك في سياسة الخصوصية. ويُعدّ ثابت "عمل عميل محض" القفلَ المعماري الذي يُبقي Bladder Diaries خارج المحيط التنظيمي، فيما يُمثّل كتالوج صيغ الملفات المنحدرَ التشغيلي الذي يُيسِّر مع ذلك تسليم البيانات المهيكلة إلى السجل.

ما الـ OID المخصص للـ CodeSystem الذي يحمل البادئة 2.25.* في سجل التدقيق لديّ؟

يرى المُستقبِلون الذين يدققون الوثيقة الواردة بحسب الـ CodeSystem في سجل التدقيق معرّفَ كائن (OID) خاصاً بـ Bladder Diaries بالصيغة 2.25.<uuid-decimal>. وهذا متعمَّد، ويستحق توضيحاً موجزاً، لأن فرق IT السريرية تُشير أحياناً إلى المعرّفات غير المعروفة بوصفها مخاوف أمنية.

والـ OID مُعرِّف هرمي مُسجَّل ضمن شجرة عالمية (قوس OID ضمن ISO/IEC 9834). وتستخدم معايير HL7 المعرّفات لتسمية أنظمة الترميز تسمية لا لبس فيها: فمعرّف LOINC هو 2.16.840.1.113883.6.1، ومعرّف SNOMED CT هو 2.16.840.1.113883.6.96. ويقابل كلُّ معرّف سلطةً مُسجَّلة تتولى صيانة الرموز.

ولا يغطي LOINC المعياري حتى الآن المقاييس المحسوبة الخمسة لـ Bladder Diaries (MVV و AVV و NPi و 24hVV و FVC) تغطيةً كاملة. إذ يملك LOINC رموزاً للأحجام الأساسية (مثل 28604-5 لـ Voided volume و 28649-0 لـ Urine output 24 hour)، لكنه لا يملك بعدُ رموزاً للمقاييس المحسوبة الخاصة بمفكرة المثانة بالشكل الدقيق الذي يطلبه إطار IPC. ويُصدر الترميز الهجين رمزَ LOINC حيث يتوفر، ورمز Bladder Diaries المخصص دائماً، بحيث يحصل المُستقبِل على ترميز قياسي يَستند إليه في عمليات البحث، وترميز دقيق يَستند إليه في عمليات الحساب.

ويحتاج الـ CodeSystem المخصص إلى OID. وعِوضاً عن تقديم طلب للحصول على قوس مُسجَّل عبر HL7 (وهي عملية تمتد عدة أشهر)، يستخدم Bladder Diaries القوس 2.25.* بمقتضى RFC 4122 §4.5، الذي يُجيز لأي طرف اشتقاقَ OID فريد عالمياً من UUID بمعاملة الـ UUID بوصفه عدداً صحيحاً عشرياً. ويكون المعرّف الناتج فريداً دون حاجة إلى تسجيل، وقابلاً للتتبع، ومتوافقاً مع معيار HL7 لمعرّفات الـ CodeSystem. ويستطيع فريق IT السريري توثيق هذا المعرّف بوصفه صادراً عن Bladder Diaries (موافقة لمرة واحدة في قائمة OID المسموح بها)، فيستمر سجل التدقيق في التدفق على نحو طبيعي.

ما الذي ينبغي سؤال قسم IT لديكم عنه قبل أول عملية تصدير

تُحاذي خمسة أسئلة التوقعاتِ قبل أول عملية تصدير لمريض. وتُحدِّد الإجابات صيغةَ الملف وسطحَ المدخل المُلائمَين:

1. هل ندعم استيعاب FHIR R4؟ تَدعم معظم منظومات السجلات الإلكترونية المُنشَرة بحلول 2026 معيارَ FHIR R4 بدرجة ما، وإنما يختلف الأمر في سطح المدخل (تطبيق SMART on FHIR، أو FHIR Inbox، أو R4/$import، أو مسار خاص بالمورِّد).
2. هل ندعم استيعاب C-CDA R2.1؟ يَقدر المُستقبِلون الذين يدعمون C-CDA R2.0 على تحليل وثائق R2.1 في الغالب (المخطط متوافق إلى الخلف)، وإن كانت تحذيرات schematron قد تختلف.
3. ما سطح تطبيق SMART on FHIR لدينا؟ بالنسبة لـ Epic و Cerner / Oracle Health: يحدد هذا السؤال ما إذا كانت حزمة FHIR تُرفع عبر تطبيق موجَّه للمريض (MyChart) أم عبر FHIR Inbox للمكتب الخلفي فقط.
4. هل عنواننا في Direct Secure Messaging قابل للاكتشاف؟ بالنسبة للسجلات الإلكترونية العيادية القديمة: يُعدّ عنوان DSM وجهةَ ملف C-CDA CCD. ويستطيع HISP لديكم تأكيد ما إذا كان العنوان منشوراً في سجلّ DirectTrust.
5. هل تربطنا شراكة بـ Kno2؟ بالنسبة لـ Prompt Health وغيره من السجلات الإلكترونية المتصلة بـ Kno2: يُعدّ مدخل Kno2 نقطةَ نهاية واحدة تُوجِّه نحو سجلات إلكترونية متعددة في المراحل اللاحقة.

سؤال إضافي: ما قواعد chart-matching المطبَّقة على ملف وارد يحمل MRN نائباً؟ تُجري بعض الجهات المُستقبِلة مطابقةً آلية بالاستناد إلى البيانات الديموغرافية (الاسم وتاريخ الميلاد والجنس والعنوان)؛ وتشترط جهات أخرى ملء Patient.identifier ملءاً تاماً. ومعرفة سياسة المُستقبِل تُخبركم ما إذا كان الملف سيتم توجيهه آلياً، أم أن موظفي المُستقبِل سيُجرون المطابقة يدوياً.

الأسئلة الشائعة

أي صيغة ملف ينبغي أن أرسل إلى Epic؟ حزمة FHIR R4 (.fhir.json). يستوعب Epic معيار FHIR R4 عبر سطح تطبيق SMART on FHIR، أو عبر FHIR Inbox إن فعّله فريق IT لديكم، أو بوصفه مرفقاً بالسجل في زيارة اعتيادية. ويجتاز الملف التحقق مقابل US Core 6.1.0.

أي صيغة ملف ينبغي أن أرسل إلى Cerner أو Oracle Health؟ حزمة FHIR R4 (.fhir.json). يستوعب Cerner / Oracle Health معيار FHIR R4 عبر المعيار نفسه. وتعتمد بعض المؤسسات على Bridges أو Code App Gallery للتوجيه؛ ويبقى المدخل FHIR في المكتب الخلفي هو المسار القياسي.

أي صيغة ملف ينبغي أن أرسل إلى Athena Health؟ حزمة FHIR R4 (.fhir.json) عبر مدخل More Disruption Please (MDP). وإن كانت نسختكم من Athena تَقتصر على مدخل CCD القديم، فأرسلوا بدلاً منها C-CDA CCD (.ccd.xml).

أي صيغة ملف ينبغي أن أرسل إلى Prompt Health؟ أيٌّ منهما. يَقبل Prompt Health كلتا الصيغتين عبر شراكة Kno2؛ ويُحوِّل المُطبِّع لدى المُستقبِل في Kno2 إلى الصيغة التي يتوقعها السجلُّ الإلكتروني في المراحل اللاحقة.

هل يَرفع Bladder Diaries بيانات مرضاي إلى أي جهة؟ لا. تُولَّد كلتا صيغتي الملف بالكامل داخل متصفحكم. ويصل الملف إلى مجلد التنزيلات المحلي لديكم؛ دون أي رفع HTTPS إلى bladderdiaries.com أو إلى أي طرف ثالث. وتصف سياسة الخصوصية ذلك بالتفصيل.

ما العنصر النائب REPLACE_WITH_MRN؟ قيمة حارسة متعمَّدة على مورد Patient الاصطناعي. تستبدلها أداة chart-matching لدى السجل الإلكتروني المُستقبِل برقم السجل الطبي الحقيقي عند الاستيعاب. ويُتيح هذا النمط إرسال الملف دون أي بيانات تُعرِّف هوية المريض، ويَترك للمُستقبِل تطبيق سياسته الخاصة لـ chart-matching.

لم يُظهر سجل التدقيق في السجل الإلكتروني لديّ معرّف CodeSystem 2.25. لا أعرفه؟* ذلك هو الـ CodeSystem المخصص لـ Bladder Diaries، المُخصَّص ذاتياً تحت قوس OID بمقتضى RFC 4122 §4.5. ويُستخدم للمقاييس المحسوبة الخمسة (MVV و AVV و NPi و 24hVV و FVC) التي لا يغطيها LOINC المعياري بعد. كما يحمل كل مقياس رمز LOINC هجيناً حيث يتوفر.

هل يمكنني إرسال الملف نفسه إلى عدة سجلات إلكترونية؟ نعم. كلتا الصيغتين محايدتان تجاه المُستقبِل. ويمكن توجيه الحزمة نفسها لـ FHIR أو ملف C-CDA CCD نفسه إلى عدة سجلات إلكترونية بالتوازي (مثل الرعاية الأولية إلى جانب إحالة الاختصاص). وتبقى عملية chart-matching في كل وجهة مستقلةً عن غيرها.

الخاتمة: جرّبوه في المفكرة التالية

تُمثّل المفكرة التالية ذات الـ 3 أيام التي تُنجزونها مع المريض على Bladder Diaries حالةَ الاختبار. افتحوا الحاسبة، وأدخلوا المفكرة، واقرؤوا المقاييس في /results، ثم اضغطوا زر التصدير الذي يطابق السجلَّ الإلكتروني المُستقبِل. يصل الملف إلى مجلد التنزيلات لديكم؛ أرفقوه عبر المدخل القياسي للسجل المُستقبِل. ويغدو لدى الطبيب عندئذ في السجل الأرقامُ المهيكلة نفسها التي أعادتها الحاسبة على الشاشة، وتبقى خوادم bladderdiaries.com خاوية، ويصل الملف القائم على المعايير إلى موضعه الصحيح: داخل السجل، إلى جانب بقية بيانات المريض.

المؤلف: Dr. Di Wu, MD, PT (عضو مؤسس في IPC). يَطرح إصدار Bladder Diaries v5.0 قابلية تشغيل بيني للسجل الإلكتروني قائمة على المعايير. المعايير المُشار إليها: HL7 FHIR R4 و HL7 C-CDA R2.1 و US Core 6.1.0 Implementation Guide و LOINC و RFC 4122 §4.5 (قوس OID المُشتق من UUID). الصورة: Vitaly Gariev على Unsplash.