اصول FHIR

 

مقدمه

منابع سریع هم‌کنش‌پذیری سلامت (Fast Healthcare Interoperability Resources) که به اختصار FHIR (با تلفظ «فایر») نامیده می‌شود، یک استاندارد HL7 است که قالب‌های داده، مؤلفه‌ها و منابع (Resources) و یک رابط برنامه‌نویسی کاربردی (API) برای تبادل اطلاعات سلامت را توصیف می‌کند.

منابع FHIR را می‌توان در قالب سامانه‌های عملیاتی ترکیب کرد که مسائل واقعی بالینی و اداری را با کسری از هزینه راهکارهای موجود حل می‌کنند. دامنه FHIR گسترده است و حوزه‌های سلامت انسان و دامپزشکی، مراقبت بالینی، سلامت عمومی، کارآزمایی‌های بالینی، امور اداری و جنبه‌های مالی را پوشش می‌دهد. این استاندارد برای استفاده جهانی و در طیف گسترده‌ای از معماری‌ها و سناریوها طراحی شده است.

 

مزایا

مزایای FHIR عبارت‌اند از:

• تمرکز قوی بر پیاده‌سازی: پیاده‌سازی سریع و آسان (بسیاری از توسعه‌دهندگان توانسته‌اند رابط‌های ساده را در مدت یک روز راه‌اندازی کنند).
• وجود کتابخانه‌های متعدد پیاده‌سازی، همراه با نمونه‌های فراوان برای آغاز سریع توسعه.
• مشخصات استاندارد برای استفاده آزاد است و هیچ محدودیتی برای استفاده از آن وجود ندارد.
• هم‌کنش‌پذیری آماده استفاده (Interoperability out-of-the-box): منابع پایه می‌توانند به همان شکل مورد استفاده قرار گیرند، اما همچنین می‌توانند با استفاده از Profileها، Extensionها وTerminologyها برای برآورده ساختن نیازمندی‌های محلی تطبیق داده شوند.
• مسیر توسعه تکاملی از HL7 Version 2  و CDA: استانداردها می‌توانند در کنار یکدیگر وجود داشته باشند و از قابلیت‌های یکدیگر بهره ببرند.
• برخورداری از بنیانی مستحکم مبتنی بر استانداردهای وب:  XML، JSON، HTTP، OAuth و غیره.
• پشتیبانی از معماری‌های RESTful، تبادل بدون وقفه اطلاعات از طریق پیام‌ها یا اسناد و معماری‌های مبتنی بر خدمت یا اصطلاحاً Service-Based Architectures.
• مشخصات فشرده () و به‌راحتی قابل درک.
• یک قالب سریال‌سازیِ قابل‌خواندن برای انسان به‌منظور سهولت استفاده توسط توسعه‌دهندگان.
• تحلیل مبتنی بر آنتولوژی همراه با نگاشت رسمی برای تضمین صحت.

 

خاستگاه‌ها

تا اواسط سال 2009، HL7  سال‌های زیادی را صرف توسعه استاندارد v3 کرده بود؛ استانداردی که بر پایه HL7 RIM (مدل مرجع اطلاعات) و با محوریت ساختار Act-Participation-Role-Entity بنا شده بود. مشخصات v3/RIM برای رفع یکی از محدودیت‌های اصلی مشخصات HL7 v2 طراحی شده بودند؛ یعنی ماهیت موردی (ad-hoc) و ناسازگار اطلاعاتی که از طریق آن مبادله می‌شد.

مشخصات v3/RIM از نظر دامنه، جامع؛ از نظر جزئیات، دقیق؛ و از نظر کاربرد، سازگار بودند. از این جهات، این تلاش موفقیت‌آمیز بود؛ زیرا فرایند گردآوری و تحلیل نیازمندی‌ها، روش‌شناسی و ابزارهای آن، در مجموع استاندارد جدیدی را برای تبادل اطلاعات سلامت ایجاد کردند که زیربنای موفق چندین برنامه ملی بزرگ شد.CDA  که بخشی از مشخصات v3/RIM است، برای تبادل اطلاعات میان سامانه‌های سلامت با اتصال سست (loosely coupled) در سراسر جهان به‌طور گسترده مورد پذیرش قرار گرفته است؛ با این حال، علی‌رغم موفقیت در این زمینه‌ها، روشن بود که چندین مسئله وجود دارد که استاندارد v3 و خود سازمان HL7 را در یک نقطه عطف قرار داده است.

 

سازگاری (Consistency)

ضرب‌المثل مشهور «اگر یک رابط v2 را دیده باشید، فقط یک رابط v2 را دیده‌اید» در نهایت نشان داد که این موضوع بیش از آنکه درباره v2 باشد، به ماهیت مسئله‌ای که قرار بود حل شود مربوط است. در سراسر نظام سلامت، توافق اندکی درباره این وجود دارد که چه اطلاعاتی باید مورد استفاده قرار گیرد، چگونه باید نمایش داده شود و چه زمانی باید مبادله شود. اگرچه v3 در تولید تعاریف سازگار بسیار موفق بود، اما یکی از پیامدهای آن این بود که استفاده ناسازگار از آن دشوار می‌شد. سازگاری سخت‌گیرانه، یک مزیت کاذب بود.

 

پیچیدگی (Complexity)

مشخصات v3/RIM، مشخصاتی گسترده و عمیق با لایه‌های متعدد هستند. برای پیاده‌سازی موفق، طراحان و برنامه‌نویسان باید لایه‌های متعددی از اسناد را مطالعه کرده و درک کنند. علاوه بر این، مجموعه ابزارهای اختصاصی که HL7 برای اتصال این لایه‌ها به یکدیگر ایجاد کرده بود، خود نیازمند تخصص ویژه‌ای بود؛ در نتیجه، خروجی نهایی به مصنوعات مهندسی‌ای منجر می‌شد که با آنچه به‌طور معمول در صنعت استفاده می‌شد هم‌راستا نبود. پیاده‌سازی‌های واقعاً موفق v3 یا CDA (و چنین نمونه‌هایی وجود دارند) به مجموعه گسترده‌ای از کتابخانه‌های اختصاصی و قالب‌های سفارشی نیاز دارند.

 

آزمون انطباق (Conformance Testing)

یکی از محرک‌های اصلی توسعه v3، فراهم کردن امکان آزمون انطباق معنادارتر بود. با این حال، ترکیب ناسازگاری ذاتی موجود در اطلاعات مبادله‌شده و همچنین سطح انتزاعی که توسط RIM تحمیل شده بود، باعث شد که بهبودهای تدریجی در توانایی آزمون انطباق برای ارائه نتایج مفید، افزایش هزینه مورد نیاز را توجیه نکند.

پیاده‌سازی موفق v3 مستلزم مشارکت نزدیک کارشناسانی متعهد بود (که اغلب خود از نویسندگان اصلی مشخصات بودند یا بعدها به آن تبدیل می‌شدند) و همچنین نیازمند منابع مالی برنامه‌های ملی با بودجه‌ای بیش از یک میلیارد دلار بود. اگرچه برنامه v3/RIM به اهداف تعریف‌شده خود دست یافته بود، اما به‌تدریج آشکار شد که نتوانسته است به اهداف گسترده‌تر HL7 در ارزان‌تر و آسان‌تر کردن هم‌کنش‌پذیری دست یابد (و از منظر بقا نیز نتوانسته بود استانداردهایی تولید کند که در بازار رقابت کنند، زیرا استانداردهای هم‌کنش‌پذیری سلامت خود یک بازار مستقل محسوب می‌شوند).

در پاسخ به افزایش آگاهی نسبت به این مسئله،HL7  یک گروه کاری با عنوانFresh Look  تشکیل داد تا بررسی کند که HL7 چگونه می‌تواند بهترین راهکارهای هم‌کنش‌پذیری را ایجاد کند، بدون آنکه هیچ پیش‌شرطی درباره ماهیت این راهکارها وجود داشته باشد. پروژه FHIR  از دل این فعالیت‌ها و همچنین از دو دسته ملاحظات دیگر شکل گرفت. نخست، بررسی نقاط قوت و ضعف استانداردهای موجود، و دوم، جست‌وجوی نمونه‌های موفق از هم‌کنش‌پذیری که به‌خوبی اجرا شده بودند. به‌عنوان یک نمونه موفق، نخستین پیش‌نویس FHIR (که در آن زمان با نام  RFH، مخففResources for Health  شناخته می‌شد) بر اساس یک نمونه متداول از یک API مبتنی بر REST طراحی شد. این نوشتار، اصول بنیادی مشخصات FHIR را توصیف می‌کند؛ ترکیبی از انتخاب‌های فنی و فلسفه‌های مدیریتی که در کنار یکدیگر، آن را به رویکردی نوآورانه و جذاب برای هم‌کنش‌پذیری سلامت تبدیل کرده‌اند.

 

APIها

مشخصات هم‌کنش‌پذیری را می‌توان در چند رویکرد مختلف دسته‌بندی کرد:

• پیام‌ها (Messages): مجموعه‌ای از اطلاعات ثابت را تعریف می‌کنند که هنگام وقوع یک رویداد مشخص می‌توانند میان برنامه‌های کاربردی مبادله شوند.
• خدمات (Services): مجموعه‌ای از عملیات عملکردی را تعریف می‌کنند که یک سامانه برای استفاده سایر سامانه‌ها ارائه می‌دهد، همراه با انتظارات رفتاری مرتبط با آن‌ها.
• اسناد (Documents): مجموعه‌ای از بسته‌های اطلاعاتی ثابت را تعریف می‌کنند که می‌توانند مبادله یا برای استفاده در آینده ذخیره شوند.

در نهایت، هم‌کنش‌پذیری عملی مستلزم آن است که سامانه‌ها درباره این موارد توافق داشته باشند: چه چیزی مبادله می‌شود، چه زمانی مبادله می‌شود و چرا مبادله می‌شود. بنابراین، همه این رویکردها در نهایت به یک مقصد مشترک منتهی می‌شوند؛ تفاوت آن‌ها در این است که کدام بخش‌های راهکار کلی استانداردسازی می‌شوند و کدام بخش‌ها به اختیار پیاده‌سازان واگذار می‌گردند. برای مثال، یک سامانه مبتنی بر پیام معمولاً توصیف اطلاعات را به مجموعه مشخصی از فناوری‌ها مقید می‌کند تا امکان تبادل پیام‌ها فراهم شود، اما تصمیم‌گیری درباره نوع خدمتی که باید ارائه شود را به پیاده‌سازان سامانه واگذار می‌کند. در مقابل، رویکرد مبتنی بر خدمات، خدمات ارائه‌شده و اطلاعات مبادله‌شده را (تا حدی) تعریف می‌کند، اما اتصال آن‌ها به فناوری‌های مشخص را بر عهده پیاده‌ساز می‌گذارد.

در اواسط دهه 2000، معماری سرویس‌گرا (Service Oriented Architecture  - SOA) به روشی محبوب برای مدیریت مجموعه‌ای از سامانه‌های ناهمگون، به‌ویژه در سازمان‌های بزرگ، تبدیل شد. به‌طور معمول،SOA  به معنای ایجاد مجموعه‌ای از خدمات بود که از طریق یک گذرگاه خدمات سازمانی (Enterprise Service Bus) و بر پایه مجموعه‌ای از وب‌سرویس‌های مبتنی بر استاندارد SOAP به یکدیگر متصل می‌شدند. در پاسخ به این روند، HL7  با Object Management Group (OMG)  همکاری کرد تا در قالب پروژه Healthcare Services Specification Project  مشخصات مبتنی بر خدمات را توسعه دهد. این پروژه تعدادی خدمت مفید را تعریف کرد. با این حال، این پروژه هرگز به حدی از مقبولیت و پذیرش نرسید که بتواند هم‌کنش‌پذیری را متحول کند؛ دلایل مختلفی برای این موضوع وجود داشت که شاید مهم‌ترین آن‌ها این بود که مسئله پیچیدگی را حل نکرد.

در تمام این مدت، شکل دیگری از هم‌کنش‌پذیری نیز وجود داشت که رابط برنامه‌نویسی کاربردی (API) نامیده می‌شد؛ یک API مجموعه‌ای از خدماتی است که توسط یک کتابخانه نرم‌افزاری ارائه می‌شود و برنامه دیگری می‌تواند برای دستیابی به اهداف خود از آن‌ها استفاده کند. این همان نوع خدمات هم‌کنش‌پذیری است که سیستم‌عامل‌ها بر پایه آن ساخته شده‌اند.

از نظر تاریخی، APIها به دلیل محدودیت‌های فناوری، تنها قادر به ارائه خدمات درون یک فرایند و روی یک رایانه بودند؛ اما بعدها این قابلیت توسعه یافت تا امکان فراخوانی عملیات از طریق شبکه نیز فراهم شود. در دسته‌بندی پیام/خدمت/سند، یک API در واقع یک رابط خدماتی یا  Service Interfaceمحسوب می‌شود، هرچند بسیاری از افراد آن را به این شکل تلقی نمی‌کنند. به‌طور معمول، یک API به فناوری مشخصی وابسته است و بر ارائه تعریفی عینی از مجموعه‌ای از قابلیت‌ها که توسط سامانه ارائه‌دهنده تعریف شده‌اند تمرکز دارد. این تعریف تلاش می‌کند نحوه استفاده از API را دیکته نکند، زیرا تعاریف وابسته به موارد استفاده خاص معمولاً به نتایجی شکننده منجر می‌شوند.

با پیشرفت فناوری‌های پشتیبان رابط‌های برنامه‌نویسی و افزایش توانایی آن‌ها در پشتیبانی از عملیات توزیع‌شده، مرز میان خدمات/SOA و APIها به‌تدریج کم‌رنگ شد. در نهایت، این روند به تعریفREST  (Representational State Transfer) منجر شد.

 

رابط‌های  RESTful

مفهوم REST نخستین بار در سال 2000 توسط روی فیلدینگ (Roy Fielding) در رساله دکتری او به‌عنوان مجموعه‌ای از محدودیت‌های طراحی، روش‌ها و معماری‌هایی تعریف شد که به ایجاد رابط‌هایی مقیاس‌پذیر، قابل اعتماد و آسان برای استفاده منجر می‌شوند. از آن زمان تاکنون، جامعه‌ای رو به گسترش شکل گرفته است که بسیاری از اصول بنیادین REST را پذیرفته است. امروزه تقریباً تمامی شرکت‌های فناوری، APIهای وب خود را با استفاده از الگوی RESTful پیاده‌سازی می‌کنند.

FHIR  یک مشخصات RESTful است؛ FHIR تا حد امکان تلاش می‌کند از اصول RESTful پیروی کند. این موضوع بیانگر پذیرش تأثیر عمیقی است که رابط‌های RESTful بر صنعت داشته‌اند. این رابط‌ها نشان داده‌اند که می‌توان اکوسیستم‌های بزرگ مبتنی بر یکپارچه‌سازی را به‌سرعت ایجاد کرد، توسعه‌دهندگان به‌آسانی می‌توانند با خدمات RESTful یکپارچه شوند و این خدمات از مقیاس‌پذیری بسیار بالایی برخوردار هستند.

اصول پایه REST عبارت‌اند از:

1) رابط یکنواخت (Uniform Interface): منابع منفرد با استفاده از URLها شناسایی می‌شوند و می‌توانند به شکل‌های مختلفی نمایش داده شوند (برای مثال XML یا JSON). مشتریان (Clients) از طریق این نمایش‌ها و با استفاده از پیام‌های خودتوصیف‌گر (Self-Descriptive Messages) )، منبع را دستکاری می‌کنند. ابررسانه (Hypermedia) و ابرمتن (Hypertext) به‌عنوان موتور انتقال وضعیت (State Transfer) عمل می‌کنند.

2) تعاملات بدون وضعیت (Stateless Interactions): هیچ بخشی از زمینه (Context) مشتری بین درخواست‌ها در سمت سرور ذخیره نمی‌شود؛ بنابراین تمامی اطلاعات لازم برای پردازش درخواست در URL، سرآیندها (Headers) یا بدنه (Body) درخواست قرار دارد.

3) قابلیت ذخیره‌سازی در حافظه نهان (Cacheable): پاسخ‌ها می‌توانند در حافظه نهان ذخیره شوند و هر پاسخ باید مشخص کند که قابل ذخیره‌سازی هست یا خیر.

4) جدایی مشتری و سرور (Client and Server Separation): مشتری و سرور از یکدیگر مستقل هستند؛ بنابراین مشتری درگیر نحوه ذخیره‌سازی داده‌ها نمی‌شود و سرور نیز مسئول رابط کاربری نیست.

5) سامانه لایه‌ای (Layered System): در هر لحظه، مشتری نمی‌تواند تشخیص دهد که به سرور نهایی متصل است یا به یک واسطه میانی. این واسطه‌ها می‌توانند به اعمال سیاست‌های امنیتی، متعادل‌سازی بار (Load Balancing) و سایر وظایف مشابه کمک کنند.

 

یکی از موضوعات بحث‌برانگیز مرتبط با REST این است که دقیقاً چه چیزی باعث می‌شود یک رابط با این اصول پایه منطبق باشد. به همین دلیل، بسیاری از رابط‌ها خود را RESTful معرفی می‌کنند تا از ورود به بحث درباره میزان انطباقشان با REST اجتناب کنند.FHIR یک رابط RESTful است؛ اما مشخصات FHIR، REST را به‌عنوان یک عقیده یا آموزه تغییرناپذیر تلقی نمی‌کند. در عوض، فلسفهFHIR انجام آن چیزی است که در عمل مؤثر است و ترجیحاً همان چیزی که اکثر رابط‌های RESTful دیگر انجام می‌دهند.

دو تفاوت کلیدی میان FHIR و نوع رابط‌های RESTful که معمولاً توسط ارائه‌دهندگان خدمات ابری عرضه می‌شوند وجود دارد:

1. بیشتر خدمات RESTful مبتنی بر ابر توسط یک ارائه‌دهنده واحد، برای برآورده ساختن یک هدف کسب‌وکاری مشخص و بر روی یک سرور واحد ارائه می‌شوند. در مقابل، FHIR یک مشخصات عمومی برای تبادل داده میان چندین طرف مختلف است. نتیجه این موضوع آن است که مشخصات FHIR گسترده‌تر و انعطاف‌پذیرتر است.
2. اطلاعات سلامت هرگز صرفاً به تبادل از طریق APIهای RESTful محدود نخواهد شد؛ دلایل متعددی برای استفاده از سایر انواع تبادل اطلاعات وجود دارد و مشخصات FHIR نیز برای پشتیبانی از رویکردهای مبتنی بر پیام (Messaging) و سند (Document) گسترش یافته است.

FHIR از این جهت یک مشخصات RESTful محسوب می‌شود که رویکردهای RESTful گزینه ترجیحی آن هستند و محتوای تعریف‌شده باید در چارچوب الگوی RESTful قابل استفاده باشد. با این حال، امکان تعریف مشخصات مبتنی بر خدمات نیز وجود دارد که بتوانند بخش‌هایی از رابط RESTful را تکمیل یا جایگزین کنند.

 

مخزن  Repository)

به‌عنوان یک مشخصه RESTful،FHIR  حول مفهوم مخزن (Repository) سازمان‌دهی شده است؛ مخزنی که فهرستی از منابع یک نوع خاص را در خود نگهداری می‌کند. این مفهوم به‌طور صریح درURLهای تعریف‌شده توسط FHIR نمایش داده می‌شود. نمونه‌ای از یک URL  معمولی در FHIR:

http://server.example.com/fhir/Patient/23455

 

از نظر ساختاری، این URL از سه بخش تشکیل شده است (جدول 5.1):     [base-address]/[Type]/[id]

بخش	شرح	مثال
base-address	یک خدمت سیستمی FHIR را شناسایی می‌کند؛ یعنی سروری که اطلاعات را مطابق با مشخصات FHIR در دسترس قرار می‌دهد.	http://server.example.com/fhir
Type	یک خدمت نوع (Type Service) در FHIR را شناسایی می‌کند که مجموعه‌ای از منابع با یک نوع یکسان را مدیریت می‌کند. نوع باید یکی از انواع تعریف‌شده در مشخصات FHIR باشد.	Patient
Id	یک خدمت نمونه (Instance Service) در FHIR را شناسایی می‌کند که یک نمونه از یک منبع را درون آن مجموعه مدیریت می‌کند.	23455

بیشتر قابلیت‌های یک رابط FHIR از طریق سه خدمت پایه فراهم می‌شود (جدول 5.2)

خدمت	شرح
خدمت نمونه (Instance Service)	به یک مشتری اجازه می‌دهد محتوای فعلی یک منبع را بازیابی کند، محتوای آن را به وضعیت جدیدی به‌روزرسانی نماید، منبع را حذف کند یا تاریخچه تغییرات آن را مشاهده نماید.
خدمت نوع (Type Service)	به یک مشتری اجازه می‌دهد در میان منابع موجود جستجو کند، یک نمونه جدید از یک منبع ایجاد نماید یا تاریخچه تمامی تغییرات مربوط به منابع آن نوع را دریافت کند.
خدمت سیستم (System Service)	به یک مشتری اجازه می‌دهد مشخص کند چه قابلیت‌هایی توسط سیستم ارائه می‌شود، پردازش‌های دسته‌ای (Batch) و تراکنش‌ها را در میان چندین نوع منبع انجام دهد و تاریخچه تمامی تغییرات اعمال‌شده بر همه منابع را دریافت کند.

سرورها بر اساس موارد استفاده‌ای که پشتیبانی می‌کنند، تعیین می‌کنند که کدام قابلیت‌ها برای کدام انواع منابع در دسترس باشند. سرورها باید یک بیانیه انطباق (Conformance Statement) بازگردانند تا مشتری بتواند تشخیص دهد چه قابلیت‌هایی توسط آن‌ها ارائه می‌شود. سروری که بیانیه انطباقی ارائه کند که در آن اعلام شده هیچ قابلیت دیگری ارائه نمی‌شود، کاملاً منطبق با استاندارد است (هرچند کاربرد چندانی نخواهد داشت).

API مربوط به FHIR رویکردی رکوردمحور (Record-Centric) برای تبادل داده فراهم می‌کند. به‌جای آنکه مشتری از سرور بخواهد عملیاتی خاص را انجام دهد، مشتری به سرور اعلام می‌کند که محتوای رکورد باید چگونه باشد. این خدمات معمولاً با عنوان خدماتCRUD شناخته می‌شوند:

• Create (ایجاد)
• Read (خواندن)
• Update (به‌روزرسانی)
• Delete (حذف)

توجه داشته باشید که در سامانه‌های سلامت، تعداد بسیار کمی از رکوردها واقعاً حذف می‌شوند. علاوه بر این خدمات پایه که برای تمامی انواع منابع تعریف‌شده در FHIR قابل اعمال هستند،FHIR  امکان تعریف خدمات ویژه اضافی را نیز فراهم می‌کند که قابلیت‌هایی فراتر از خدمات ساده CRUD ارائه می‌دهند. خود FHIR چندین خدمت مفید را تعریف کرده است؛ از جمله پرسش از سرور درباره معتبر بودن یک منبع؛ پیوند دادن دو بیمار به یکدیگر؛ بازیابی تمامی رکوردهای مرتبط با یک بیمار مشخص. علاوه بر این، سرورها می‌توانند خدمات اختصاصی خود را نیز تعریف کنند.

 

 منابع (Resources) 

انواع منابع (Resource Types): بخش عمده‌ای از محتوای مهم مشخصات FHIR در تعریف منابع قرار دارد. FHIR  قریب به 145 نوع منبع را (در نسخه R4؛ این تعداد بین نسخه‌های مختلف به‌آرامی افزایش می‌یابد) تعریف می‌کند که نمایانگر انواع بسیار متفاوتی از محتوا هستند. برای هر نوع منبع، مشخصات FHIR موارد زیر را تعریف می‌کند:

• دامنه و هدف تعریف منبع، همراه با اطلاعات زمینه‌ای تکمیلی درباره نحوه استفاده مناسب از آن.
• محتوای داده‌ای مشخص منبع، با استفاده از چارچوب تعریف مشترک و مجموعه‌ای از انواع داده مشترک.
• اصطلاح‌شناسی‌ها و قواعد محتوایی تکمیلی که تمامی منابع باید برای معتبر بودن آن‌ها را رعایت کنند.
• مجموعه‌ای از پارامترهای جستجوی مشترک که می‌توان از آن‌ها برای یافتن منابع و برقراری ارتباط میان آن‌ها استفاده کرد.
• نگاشت‌ها به سایر مشخصات.
• خدمات اختصاصی تکمیلی برای آن نوع منبع.

Fig. 5.1 FHIR Resources

 

منابع تعریف‌شده در مشخصات FHIR در دسته‌های Foundation، Base، Clinical، Financial  وSpecialized  طبقه‌بندی می‌شوند. ساختار سطح بالای آن‌ها در شکل 5.1 و فهرست کامل آن‌ها در جدول 5.3 نشان داده شده است.

فهرست منابع به‌تدریج و با اضافه شدن موارد استفاده جدید در حال گسترش است. توجه داشته باشید که در مشخصات FHIR هیچ پشتیبانی رسمی برای آنکه سازمان‌هایی غیر از HL7 منابع اختصاصی خود را تعریف کنند وجود ندارد و بیشتر پیاده‌سازی‌های کتابخانه‌ای نیز فرض می‌کنند که چنین اتفاقی رخ نمی‌دهد. روش دیگری برای نمایش مشخصات FHIR در شکل 5.2 نشان داده شده است.

مشخصات FHIR مجموعه‌ای از منابع دامنه‌ای (Domain Resources) را تعریف می‌کند که به تبادل داده‌های سلامت می‌پردازند. پیرامون این منابع دامنه‌ای، مشخصات FHIR موارد زیر را فراهم می‌کند:

• زیرساختی برای تبادل منابع، شامل API مبتنی بر RESTful.
• یک لایه تعریفی/هستی‌شناختی (Definitional/Ontology Layer) که توصیف‌های روایی محتوا، نگاشت‌ها به سایر مشخصات و مجموعه‌ای قابل‌پردازش از تعاریف را فراهم می‌کند.

• یک چارچوب انطباق (Conformance Framework).
• مجموعه‌ای از منابع برای مدیریت گردش‌کارها (Workflows) — درخواست‌هایی برای انجام اقدامات و موارد مشابه.

 

Fig. 5.2 Logical FHIR architecture

 

ارجاعات میان منابع (References Between Resources)

یکی از ویژگی‌های کلیدی منابع این است که به منابع دیگر ارجاع می‌دهند. برای مثال:

• منابع بالینی دارای ارجاعی به یک منبع Patient هستند تا موضوع محتوای بالینی را مشخص کنند.
• یک Condition می‌تواند به یک Observation به‌عنوان شواهد تشخیص ارجاع دهد.
• یک Composition پوششی (Wrapper) پیرامون مجموعه‌ای از ارجاعات به منابعی است که بخشی از آن Composition را تشکیل می‌دهند.

ارجاعات میان منابع، شبکه‌ای از اطلاعات درباره مجموعه‌ای از بیماران، ارائه‌دهندگان خدمت، مؤسسات، بیماری‌ها و سایر موجودیت‌ها ایجاد می‌کنند که تنها به دامنه مؤسساتی محدود می‌شود که مجموعه رکوردهای منسجم را نگهداری می‌کنند. ارجاعات با استفاده از یک URL نمایش داده می‌شوند که می‌تواند مطلق (Absolute) یا نسبی (Relative) باشد.

یک ارجاع نسبی:

<context>

  <reference value="Patient/123456" />

</context>

یک ارجاع مطلق:

<context>

  <reference value="http://server.domain/path/Patient/123456" />

</context>

ارجاعات نسبی نسبت به base-address سروری که اطلاعات را ارائه می‌کند تفسیر می‌شوند. ارجاعات مطلق این مزیت را دارند که نیازمند تفسیر نیستند و هنگام جابه‌جایی محتوا در سراسر یک سامانه، احتمال ابهام در مورد آدرس پایه صحیح را از بین می‌برند. با این حال، ارجاعات نسبی این مزیت را دارند که پایدار باقی می‌مانند؛ یعنی زمانی که گروهی از منابع از یک آدرس به آدرس دیگر منتقل می‌شوند یا هنگامی که سرور ارائه‌دهنده آن‌ها از طریق چندین آدرس مختلف در دسترس قرار می‌گیرد. سرورها می‌توانند الزام کنند که ارجاعات میان منابع معتبر باشند (مشابه محدودیت‌هایForeign Key  در SQL)، اما مشخصات پایه FHIR آن‌ها را ملزم به انجام این کار نمی‌کند.

اینکه ارجاعات باید معتبر باشند یا خیر، به هدف سرور بستگی دارد؛ انتظار می‌رود سامانه‌های عملیاتی نگهداری سوابق بالینی (برای مثال EHRها) یکپارچگی ارجاعی (Referential Integrity) را الزامی کنند، اما سرورهای میان‌افزار (Middleware Servers) معمولاً چنین الزامی ندارند. پیوندها میان منابع همواره از طریق ارجاع برقرار می‌شوند و نه از طریق درج مستقیم محتوا در داخل منبع. این کار به‌منظور ایجاد پایداری فنی انجام می‌شود؛ هم برای نمایش منابع و هم برای اطمینان از اینکه برنامه‌های کاربردی هنگام حل پیوندها همواره ارجاعات را دنبال می‌کنند. با این حال، یک وضعیت خاص وجود دارد که باید به‌صورت ویژه مورد توجه قرار گیرد.

زمانی که مجموعه‌ای از منابع از یک خوراک داده ثانویه ایجاد می‌شود -برای مثال از یک پیامHL7 v2 - ممکن است پیاده‌سازان خود را در موقعیتی بیابند که در حال ایجاد منابعی هستند که هیچ هویتی (برای مثال هیچ کلید اصلی (Primary Key) ندارند و هیچ راهی نیز برای تعیین چنین هویتی وجود ندارد. یک نمونه از این وضعیت زمانی است که یک برنامه کاربردی یک پیام ORU در HL7 v2 ارسال می‌کند و تنها نام مفسر اصلی گزارش آزمایشگاه را  (OBR-32) ارائه می‌دهد:   |^Smith&John|    هیچ راهی برای ایجاد یک منبعPractitioner با شناسه مناسب از این اطلاعات وجود ندارد؛ زیرا یک پردازشگر داده ثانویه قادر نیست تعیین کند که این «جان اسمیت» دقیقاً کدام فرد است.

از آنجا که چنین استفاده‌های ثانویه‌ای از داده بسیار رایج هستند،FHIR  باید از آن‌ها پشتیبانی کند و این کار را از طریق امکان استفاده از منابع درون‌گنجانده (Contained Resources) انجام می‌دهد.

یک منبع درون‌گنجانده (Contained Resource) در Header منبعی قرار می‌گیرد که هویت آن را تعریف می‌کند:

 

قرار دادن یک منبع در داخل منبعی دیگر به این معناست که اطلاعات موجود در آن منبع در مالکیت منبع دربرگیرنده (Container) قرار دارد و هرگز نمی‌توان به‌صورت مستقل از آن به آن دسترسی داشت؛ به همین دلیل، این روشی است که باید تا حد امکان از آن اجتناب شود، زیرا مدیریت محتوا را با دشواری‌هایی مواجه می‌کند.

توجه کنید که در این مورد، این دشواری‌ها اجتناب‌ناپذیر هستند، زیرا بخشی از اطلاعات (شناسه‌ها) در منبع اولیه وجود ندارد. با این حال، برای جلوگیری از از دست رفتن اطلاعات، باید تا حد امکان از استفاده از منابع درون‌گنجانده اجتناب شود.

 

توسعه‌پذیری (Extensibility)

همه استانداردهای تبادل اطلاعات سلامت با یک چالش بنیادین مواجه هستند: کسب‌وکار ارائه مراقبت بالینی در سراسر جهان به‌شدت متنوع است. جریان‌های فرایندی و حتی شیوه‌ای که افراد درباره مسائلی که در تلاش برای حل و توصیف آن‌ها هستند می‌اندیشند، تفاوت‌های بسیار زیادی با یکدیگر دارند. علاوه بر این، هیچ نهاد استانداردگذاری مرکزی برای فرایندهای ارائه خدمات سلامت در سراسر جهان استاندارد تعیین نمی‌کند. کشورهای مختلف به دلایل فرهنگی و سیاسی، مسائل سلامت را به شیوه‌هایی کاملاً متفاوت حل می‌کنند. حتی در درون یک کشور نیز استانداردها، مقررات و سیاست‌های تأمین مالی که برای تشویق رویه‌های مشترک طراحی شده‌اند، تنها موفقیت محدودی دارند.

تمامی استانداردهای HL7، از جمله FHIR، در چنین بستر ناهمگنی توسعه یافته و پیاده‌سازی شده‌اند. استانداردهای بین‌المللی هم‌کنش‌پذیری نمی‌توانند واقعاً بسیار سخت‌گیرانه و در عین حال آسان برای استفاده باشند. در عوض، آن‌ها باید انعطاف‌پذیر باشند تا بتوانند از رویه‌های کسب‌وکاری متغیر و شیوه‌های متفاوت درک و توصیف یک موضوع واحد پشتیبانی کنند. کشورها و پروژه‌های مختلف، مشخصات استاندارد را دریافت کرده و بر اساس توافقی که می‌توانند در اکوسیستم محل تبادل اطلاعات به دست آورند، قواعد اختصاصی خود را به آن اضافه می‌کنند. این امر به معنای وجود لایه‌ها و پیچیدگی است. هیچ راه گریزی از این موضوع وجود ندارد.

به‌طور کلی، یک استاندارد می‌تواند این مسئله را به یکی از دو روش زیر مدیریت کند:

1. تمامی عناصر داده‌ای ممکن را که هر کسی ممکن است روزی از آن‌ها استفاده کند تعریف نماید و سپس به پیاده‌سازی‌های خاص اجازه دهد مواردی را که به آن نیاز ندارند حذف کنند.
2. مجموعه‌ای پایه از داده‌ها را تعریف کند و به پیاده‌سازی‌های خاص اجازه دهد هر زمان که نیاز داشتند اطلاعات اضافی را به آن اضافه کنند.

هر دو رویکرد مشکلاتی ایجاد می‌کنند. رویکرد نخست منجر به ایجاد مشخصاتی عظیم و جامع می‌شود که تولید و استفاده از آن زمان (و هزینه) زیادی نیاز دارد. بسیاری از افراد به دلیل حجم زیاد و دشواری کار با آن، ترجیح می‌دهند آن را یاد نگیرند و استفاده نکنند. رویکرد دوم باعث می‌شود هر پیاده‌سازی اطلاعات اختصاصی خود را اضافه کند و در نتیجه هیچ‌یک از آن‌ها نتوانند از طریق این اطلاعات اضافی با یکدیگر ارتباط برقرار کنند؛ بنابراین این رویکرد مقیاس‌پذیر نیست.

 

 

مشکلات Z-Segmentها

در HL7 v2، رویکرد دوم انتخاب شد. به پیاده‌سازان، پروژه‌ها و حوزه‌های قضایی اجازه داده شد که Z-Segmentها را تعریف کنند. این بخش‌ها به آن‌ها امکان می‌داد هر نوع داده اضافی را به پیام‌ها اضافه کنند یا حتی Z-Event هایی تعریف کنند که دارای پیام‌های کاملاً سفارشی باشند. بدون انعطاف‌پذیری فراهم‌شده توسط Z-Segmentها، HL7 v2 واقعاً نمی‌توانست یک استاندارد عملیاتی باشد. این به آن معنا نیست که هر پیام شامل یک Z-Segment است؛ اصلاً چنین نیست. بلکه منظور این است که اگر این سازوکار وجود نداشت، در عمل تعهد به استفاده از HL7 v2 بسیار دشوار می‌بود.

اما  Z-Segmentها به مشکلی شناخته‌شده تبدیل شده‌اند؛ استفاده از آن‌ها اغلب فاقد نظم و مستندسازی مناسب است. در بسیاری از موارد، باید با پیام‌هایی کار کنید که ناچار هستید معنای محتوای آن‌ها را حدس بزنید؛ موضوعی که آشکارا خطرات ایمنی به همراه دارد. همچنین تبادل محتوا میان فروشندگان مختلف دشوار است، زیرا هر فروشنده از Z-Segmentها به شیوه‌ای متفاوت در سطح سازمان و حتی در پروژه‌های مختلف استفاده می‌کند.

برای اجتناب از مشکلات شناخته‌شده Z-Segmentها در v2، HL7  تصمیم گرفت در v3 رویکرد نخست را اتخاذ کند: مدل‌سازی همه چیزهای شناخته‌شده در مدل‌های پایه. نتیجه این تصمیم همان مشکلاتی بود که پیش‌تر توصیف شد: زمان و هزینه فراوان برای تولید و پیاده‌سازی مشخصات. علاوه بر این، همچنان این امکان برای پیاده‌سازان وجود داشت که محتوای اضافی را در فضای نام‌های (Namespaces) XML دیگر اضافه کنند؛ قابلیتی که در عمل نیز به‌طور منظم مورد استفاده قرار می‌گیرد. در واقع، این وضعیت از Z-Segmentها نیز بدتر است، زیرا بسیاری از پیاده‌سازی‌های مبتنی بر شِما (Schema-Driven Implementations) اساساً قادر به پردازش این توسعه‌های مبتنی بر فضاهای نام جایگزین نیستند.

 

توسعه‌ها (Extensions) در  FHIR

این موضوع، یکی از پرسش‌های محوری در طراحی FHIR بود: این مسئله چگونه باید مدیریت شود؟ اهداف اصلی طراحی در این زمینه دو جنبه داشت:

• پیاده‌سازان باید بتوانند هر زمان که نیاز دارند منابع را توسعه دهند.
• استفاده از توسعه‌ها باید به‌گونه‌ای قابل مدیریت باشد که به فاجعه‌های عملیاتی منجر نشود و همانند HL7 v2 با برچسب یا انگ منفی مواجه نگردد.

هر عنصر در یک منبع FHIR می‌تواند علاوه بر محتوای معمول خود، یک یا چند عنصر توسعه (Extension) را نیز در بر داشته باشد. یک توسعه پایه از دو بخش تشکیل می‌شود: یک URL که توسعه را شناسایی می‌کند و یک مقدار. در XML، یک توسعه به شکل زیر است:

URL نه‌تنها توسعه را شناسایی می‌کند، بلکه هر سامانه‌ای می‌تواند تعریف رسمی آن توسعه را از همان URL بازیابی کند. اطلاعات موجود در این تعریف به سامانه اجازه می‌دهد داده را نمایش دهد و/یا پردازش کند.

مقدار توسعه باید یکی از انواع داده پایه FHIR باشد. این موضوع باعث می‌شود که هر پیاده‌سازی -از جمله کدی که از شمای FHIR تولید شده است- بتواند تمامی توسعه‌ها را بدون نیاز به دسترسی به تعریف آن توسعه بخواند و بنویسد.

هر پیاده‌سازی می‌تواند توسعه‌های اختصاصی خود را تعریف و منتشر کند، اما به پیاده‌سازان توصیه می‌شود به‌جای تعریف توسعه‌های جدید، از یک مخزن مرکزی برای یافتن توسعه‌های موجود استفاده کنند.HL7  همچنین پیاده‌سازان را تشویق می‌کند که توسعه‌های خود را از طریق وابسته محلی HL7 (در خارج از ایالات متحده) یا مستقیماً از طریق HL7 ثبت کنند، یا حتی از HL7 بخواهند که آن توسعه‌ها را تعریف کند؛ هرچند انجام این کار الزامی نیست. این رویکرد به پیاده‌سازان اجازه می‌دهد میزان حکمرانی (Governance) مورد نظر خود را انتخاب کنند.

این موضع مورد رضایت همه نیست و راه‌حلی کامل نیز محسوب نمی‌شود. هزینه انتخاب نکردن هم‌کنش‌پذیری کامل تنها بر عهده پیاده‌سازان نیست؛ بلکه مصرف‌کنندگان اطلاعات، از جمله سایر پیاده‌سازان، خریداران سامانه‌ها و برنامه‌های ملی نیز بخشی از این هزینه را متحمل می‌شوند.

مشخصات FHIR استفاده مسئولانه از قابلیت توسعه‌ها را از راه‌های زیر تشویق می‌کند:

• آسان‌سازی یافتن و ثبت توسعه‌ها برای تقویت استفاده مجدد از آن‌ها (با استفاده از API مربوط به FHIR).
• فراهم کردن شبکه‌های اجتماعی قوی که انتظارات مشترکی را پیرامون استفاده و ثبت توسعه‌ها گسترش می‌دهند.
• بهره‌گیری از رسانه‌های اجتماعی (برای مثال Stack Overflow) برای تشویق پیاده‌سازان به مشورت با جامعه کاربری و پرهیز از ایجاد توسعه‌های اختصاصی غیرضروری.

 

متن روایی (Narrative)

یکی دیگر از ویژگی‌های بنیادین FHIR این است که هر منبع دارای یک قالب قابل نمایش برای انسان است که متن روایی نامیده می‌شود. این ایده از CDA اقتباس شده است.

ایجاد متن روایی بر عهده سامانه یا شخصی است که منبع را تولید می‌کند. هر سامانه‌ای می‌تواند از متن روایی برای نمایش محتوای منبع به یک انسان استفاده کند، صرف‌نظر از اینکه آن سامانه محتوای داده‌ای منبع را به‌طور کامل درک کند یا حتی اصلاً آن را درک نکند.

از دیدگاه فنی، متن روایی شکلی محدود از HTML است. متن روایی می‌تواند شامل قالب‌بندی متن، فهرست‌ها، جدول‌ها، تصاویر و سبک‌ها باشد، اما نمی‌تواند دارای محتوای فعال مانند فرم‌ها، اسکریپت‌ها، اشیا یا استفاده از ذخیره‌سازی محلی (Local Storage) باشد. نمونه زیر یک منبع Patient را نشان می‌دهد که یک جدول ساده شامل نام بیمار، نشانی، اطلاعات تماس و شناسه او را نمایش می‌دهد:

 

<Patient xmlns="http://hl7.org/fhir">

<text>

<status value="generated"/>

<div xmlns="http://www.w3.org/1999/xhtml">

<tbody>

<tr>

<td>Name</td>

<td>Peter James <b>Chalmers</b> (&quot;Jim&quot;)</td>

</tr>

<tr>

<td>Address</td>

<td>534 Erewhon, Pleasantville, Vic, 3999</td>

</tr>

<tr>

<td>Contacts</td>

<td>Home: unknown. Work: (03) 5555 6473</td>

</tr>

<tr>

<td>Id</td> Top of Form

<td>MRN: 12345 (Acme Healthcare)</td>

</tr>

</tbody>

</div>

</text>

<!-- content -->

</Patient>

 

توجه داشته باشید که متن روایی دارای یک پرچم وضعیت (status flag) است تا به مصرف‌کنندگان اطلاع دهد که آیا متن روایی حاوی اطلاعاتی است که در محتوای داده‌ای وجود ندارند یا خیر؛ این موضوع ممکن است بر زمان و شرایطی که استفاده از آن مناسب تلقی می‌شود تأثیر بگذارد. درک این نکته اهمیت دارد که هدف متن روایی چیست و چه کارکردهایی را بر عهده ندارد.

نخستین کارکرد متن روایی، ایفای نقش یک سازوکار پشتیبان و شبکه ایمنی است. متن روایی حداقلی را فراهم می‌کند تا اطمینان حاصل شود که همواره راهی برای برنامه‌های کاربردی وجود دارد تا محتوای منبع را به کاربر نمایش دهند، هرگاه دلیلی وجود داشته باشد که نشان دهد سامانه ممکن است آن را به طور کامل درک نکرده باشد.

برای مثال، یک سامانه ممکن است فهرستی از آزمون‌های تشخیصی را در قالب یک جدول خلاصه برای یک کاربر بالینی نمایش دهد. این جدول خلاصه از داده‌های استخراج‌شده از منابع متعدد ساخته می‌شود. طراح سامانه ممکن است گزینه‌ای با عنوان «مشاهده اصل» (see original) به رابط کاربری اضافه کند تا کاربر بتواند متن روایی اصلی را مشاهده کرده و شخصاً تأیید کند که سامانه محتوا را به درستی پردازش کرده است.

بدیهی است که ترجیح داده می‌شود طراحان سامانه از پیش اطمینان داشته باشند که هیچ امکانی برای سوءبرداشت از محتوای منابع وجود ندارد، اما در عمل دستیابی به این هدف دشوارتر از آن چیزی است که به نظر می‌رسد. برای نمونه، تغییر در ترتیبات کسب‌وکاری ممکن است موجب ایجاد یکپارچه‌سازی‌های جدید با سرعتی بیشتر از توان سازگاری طراحی پایه سامانه شود. این وضعیت به واسطه انعطاف‌پذیری فراهم‌شده توسط معماری وب و قابلیت توسعه‌پذیری FHIR حتی محتمل‌تر نیز می‌شود.

متن روایی همچنین می‌تواند توسط نرم‌افزارهای ساده مورد استفاده قرار گیرد تا با دانش تخصصی اندک یا حتی بدون دانش تخصصی در زمینه پردازش محتوای منابع، قابلیت‌های مفیدی ارائه دهند.

ایده یکپارچه‌سازی متن روایی و داده، فراتر از یک سازوکار پشتیبان ایمنی یا صرفاً یک تسهیل‌کننده کاربردی است. در بنیادی‌ترین سطح، اطلاعات بالینی ترکیبی از یک روایت داستانی به همراه داده‌های پشتیبان است:

پرونده پزشکی داده نیست. همان‌گونه که بسیاری از انواع نوشتار حاوی داده هستند، پرونده پزشکی نیز داده در بر دارد؛ اما خودِ آن داده نیست و صرفاً مخزنی هم نیست که داده‌ها در آن ریخته شوند. اگرچه ماده خام آن اطلاعات است -که بخشی از آن، و این نکته بسیار مهم است، تنها با واژه‌ها قابل بیان است و نه با اعداد- یک پرونده پزشکی کامل، اطلاعاتی است که به واسطه دانش، مهارت و تجربه پزشک و با انگیزه درمانگری، به درکی از تجربه انسانی تبدیل شده است؛ درکی که مراقبت از بیمار را امکان‌پذیر می‌سازد.

گنجاندن متن روایی در هر منبع، این دوگانگی را به یکی از ویژگی‌های بنیادین مشخصات FHIR تبدیل می‌کند.

 

نرم‌افزارهای تخصصی

انتظار می‌رود نرم‌افزارهای تخصصی که از فرایندهای مستقیم بالینی پشتیبانی می‌کنند، از داده‌های موجود در منابع استفاده کنند. چنین نرم‌افزارهایی باید داده‌ها را به طور کامل درک کنند تا بتوانند خودشان منابع را ایجاد کرده و متن روایی را تولید نمایند. متن روایی برای پشتیبانی از این موارد کاربردی طراحی نشده است و همچنین قرار نیست پیاده‌سازی آن‌ها را دشوارتر کند.

لزومی ندارد متن روایی ارائه‌ای بسیار کارآمد یا حتی زیبا از محتوای منبع باشد، هرچند می‌تواند چنین باشد. کارکرد اصلی آن، ایفای نقش یک پشتیبان ایمنی بالینی است؛ به این معنا که تنها یک شیوه ارائه کافی است و نیازی به ارائه‌های متفاوت برای زمینه‌های مختلف وجود ندارد.

وجود متن روایی به این معناست که اطلاعات درون منبع تکرار می‌شوند. بنابراین احتمال بروز ناسازگاری میان متن روایی و داده‌های پشتیبان وجود دارد. در صورت وقوع چنین وضعیتی، درباره محتوای صحیح منبع ابهام ایجاد می‌شود و این ابهام تنها با مراجعه به سامانه مبدأ آن منبع قابل رفع است.

در عمل، پیاده‌سازان اغلب در مراحل اولیه رابط‌هایی ایجاد می‌کنند که در آن‌ها متن روایی و داده‌ها با یکدیگر ناسازگار هستند. تقریباً همیشه این موارد ناشی از خطاهای پیاده‌سازی در یکی از این دو بخش است. یکی از مزایای متن روایی این است که کاربران نهایی نیز می‌توانند در شناسایی چنین خطاهایی مشارکت کنند، به جای آنکه قربانی این خطاها شوند.

یکی از قابلیت‌هایی که سکوهای مرجع پایه ارائه می‌کنند، امکان تولید خودکار یک متن روایی اولیه از روی داده‌های موجود است. این قابلیت می‌تواند به کاربران کمک کند تا سازگاری میان داده‌ها و متن روایی ارائه‌شده را بررسی نمایند. در عمل، متن روایی یک سازوکار ارزشمند برای کنترل کیفیت داده‌ها فراهم می‌کند.

در واقع وجود متن روایی در تمامی منابع الزامی نیست و برخی پیاده‌سازان تصمیم می‌گیرند که در محدوده کاربردی محدود خود از آن بهره‌ای نمی‌برند و بنابراین آن را تولید نکنند. معمولاً این رویکرد ممکن است برای یک جامعه کوچک و به‌شدت محدود که محتوا را تنها میان اعضای خود مبادله می‌کند، دارای سطح بالایی از حاکمیت بوده و از چارچوب آزمون قدرتمندی برای تضمین تبادل ایمن داده‌ها برخوردار است، مناسب باشد. در چنین شرایطی ممکن است ارزش افزوده متن روایی نادیده گرفته شود و توجه افراد صرفاً به هزینه‌های تولید، آزمون، انتقال و ذخیره‌سازی آن معطوف گردد. متأسفانه جوامع محدود و بسته به ندرت برای همیشه به همین سادگی باقی می‌مانند. در مقطعی از آینده، این مرزها از میان خواهند رفت و منابع هم به سمت داخل و هم به سمت خارج، میان این جامعه و سایر جوامع خارجی جریان خواهند یافت. در آن زمان، تصمیم اولیه بسیار کوتاه‌بینانه به نظر خواهد رسید. به همین دلیل، به پیاده‌سازان اکیداً توصیه می‌شود که همواره برای اهداف ایمنی بالینی، حداقل یک متن روایی پایه را در منابع خود درج کنند.

 

جامعه FHIR

خود FHIR از دو بخش تشکیل شده است که ارتباطی تنگاتنگ با یکدیگر دارند: مشخصات فنی که بیشتر افراد بر آن تمرکز می‌کنند، و جامعه‌ای که آن را ایجاد و نگهداری می‌کند که ارزش واقعی در آن نهفته است (جدول 5.4).

جدول 5.4 نقش‌های جامعه باز و استانداردهای باز

 

استاندارد باز (Open Standard)	جامعه باز (Open Community)
نحوه تبادل اطلاعات سلامت را توصیف می‌کند.	تبادل اطلاعات سلامت را آسان‌تر می‌کند.
در مالکیت عمومی (Public Domain) قرار دارد:   http://hl7.org/fhir	مشارکت باز - هر فردی می‌تواند در آن مشارکت داشته باشد.
یک API وب است - هر جا که ممکن باشد از استانداردهای وب استفاده می‌کند.	از زیرساخت‌های وب (برای مثال رسانه‌های اجتماعی) استفاده می‌کند.
تداوم و سازگاری با استانداردهای موجود حوزه سلامت را حفظ می‌کند.	تحت رهبری HL7 است و ارتباط عمیقی با جامعه سلامت در سراسر جهان دارد.

 

مشخصات فنی، ثبت مکتوب نتایج بحث‌های پرشور جامعه درباره نحوه حل مسائل حوزه سلامت است. همین اشتیاق است که موجب پذیرش و موفقیت این مشخصات می‌شود. علاوه بر این، جامعه FHIR یک جامعه باز است و هر فردی می‌تواند در آن مشارکت کند. اگرچه HL7 کنترل مشخصات FHIR و علائم تجاری آن را حفظ کرده است، اما از این کنترل برای فراهم کردن امکان مشارکت همگان استفاده می‌کند. هرچند مشارکت در این جامعه مستلزم پرداخت هزینه مالی نیست، اما حضور در آن یک فرایند دوطرفه است؛ هرچه فرد زمان و اشتیاق بیشتری صرف کند، دستاورد بیشتری نیز به دست خواهد آورد.

یکی از نتایج کلیدی وجود هم‌زمان یک جامعه باز و یک استاندارد باز این است که FHIR می‌تواند روابط مستحکمی با سایر جوامع تدوین استاندارد و پیاده‌سازی برقرار کند.

 

ارتباط با سایر سازمان‌ها

HL7 طی چند دهه گذشته به منظور همکاری در طراحی راهکارهای حوزه سلامت، روابط کاری مستحکمی با سازمان‌های دیگر ایجاد کرده است. مهم‌ترین این سازمان‌ها عبارت‌اند از: DICOM، IHE، SNOMED International،LOINC  و SMART Health.

 

DICOM

DICOM یک استاندارد به‌طور گسترده پذیرفته‌شده برای تبادل تصاویر پزشکی (مانند تصاویر رادیوگرافی، سی‌تی‌اسکن، ام‌آر‌آی و غیره) است. HL7 با جامعه DICOM همکاری می‌کند تا اطمینان حاصل شود که رابط میان زیست‌بوم تصویربرداری پزشکی و سامانه گسترده‌تر سلامت، به صورت یکپارچه عمل می‌کند.

DICOMweb  استاندارد DICOM برای تصویربرداری پزشکی مبتنی بر وب است. این استاندارد مجموعه‌ای از خدمات RESTful  را فراهم می‌کند که به توسعه‌دهندگان وب امکان می‌دهد با استفاده از ابزارهای استاندارد صنعت، از قابلیت‌های تصاویر پزشکی بهره‌برداری کنند.DICOMweb  و HL7 FHIR استانداردهایی مکمل یکدیگر هستند. FHIR مدل اطلاعاتی مربوط به اطلاعات سلامت را فراهم می‌کند، در حالی که DICOMweb اطلاعات و محتوای تصویربرداری را ارائه می‌دهد. گروه کاری WG-20 در DICOM با عنوان «یکپارچه‌سازی سامانه‌های تصویربرداری و سامانه‌های اطلاعاتی» از نزدیک با گروه کاری «یکپارچه‌سازی تصویربرداری» در HL7 همکاری می‌کند تا این خدمات همسو و هماهنگ باقی بمانند.

FHIR  شامل منبعی به نام ImagingStudy  است که برای توصیف ارجاعات به مطالعات تصویربرداری موجود به کار می‌رود. این منبع می‌تواند شامل ارجاعاتی به URL پایه یک سرور DICOMweb باشد و در این صورت، پیاده‌ساز می‌تواند در صورت نیاز نمونه‌هایDICOM (از جمله تصاویر JPEG رندرشده) را جستجو و بازیابی کند.

 

IHE

IHE برای حل مشکلی ایجاد شده است که HL7 قادر به حل آن نیست؛ یعنی نبود توافق بر سر موارد کاربرد (Use Cases). IHE موارد کاربرد مشخصی را انتخاب می‌کند که بخشی از جامعه بر سر آن‌ها توافق دارند و تا حد امکان میزان اختیاری بودن را کاهش می‌دهد.

IHE مشکل اصلی اختلاف‌نظر درباره موارد کاربرد را در حالت کلی حل نمی‌کند؛ بلکه با انتخاب موارد کاربرد محدودتر، انعطاف‌پذیری را کاهش می‌دهد و احتمال عملکرد صحیح «بدون نیاز به پیکربندی اضافی» را افزایش می‌دهد، اما در عوض این راهکارها تنها برای جمعیت کوچک‌تری از ذی‌نفعان بالقوه قابل استفاده خواهند بود.

جامعه FHIR از نزدیک با IHE همکاری می‌کند تا منابع AuditEvent، DocumentReference  و DocumentManifest  را برای پشتیبانی از ارائه مخازن XDS از طریق یک رابط RESTful فراهم کند. این رویکرد تحت عنوان Mobile Health Documents (MHD)  با XDS on FHIR  توصیف شده است. IHE  همچنین همانند سایر استانداردهای HL7، پروفایل‌هایی از منابع FHIR و توابعAPI  آن منتشر می‌کند.

 

SNOMED International

HL7 به روش‌های زیر با SNOMED International همکاری می‌کند:

• اطمینان از اینکه نحوه استفاده صحیح از SNOMED CT در مشخصات HL7 به‌روشنی تبیین شده باشد.
• HL7 دارای یک فضای نام توسعه (Extension Namespace) برای SNOMED CT است که می‌تواند در آن، محتوا را با استفاده از چارچوب تعریف‌گری SNOMED CT تعریف کند (اگرچه تاکنون از این امکان استفاده نکرده است).
• ارتقای سازگاری بیشتر میان چارچوب‌های تعریف‌گری HL7 و SNOMED CT.

در FHIR، سازمان IHTSDO و HL7 به‌صورت مشترک مالک صفحه «استفاده از SNOMED CT با FHIR» هستند. علاوه بر این، HL7  و SNOMED International برای تولید نگاشت‌هایی میان عناصر منابع و معادل‌های تعریفی آن‌ها درSNOMED CT، در منابعی که این کار مناسب باشد، با یکدیگر همکاری می‌کنند.

 

LOINC

LOINC  و FHIR به‌صورت مشترک و در همکاری با یکدیگر توسعه یافته‌اند. سرور اصطلاح‌شناسی FHIR مربوط به LOINC امکان دسترسی برنامه‌نویسی‌شده به محتوای LOINC را با استفاده از منابع CodeSystem،ValueSet و ConceptMap  در FHIR فراهم می‌کند.

 

SMART Health

SMART Health تیمی است که در Boston Children’s Hospital  و Harvard Medical School  فعالیت می‌کند و هدف آن ایجاد نوآوری در نظام سلامت از طریق فراهم‌کردن امکان اجرای برنامه‌های کاربردی بر روی سامانه‌های پرونده الکترونیک سلامت (EHR) است؛ به همان سادگی که برنامه‌ها بر روی تلفن‌های هوشمند اجرا می‌شوند.

تیم SMART همکاری عمیقی با پروژه FHIR دارد. SMART از FHIR به‌عنوان مدل محتوایی خود استفاده می‌کند و در مقابل، چارچوبی برای یکپارچه‌سازی برنامه‌های کاربردی مبتنی بر FHIR فراهم می‌آورد که در بسیاری از زمینه‌های استفاده از FHIR قابل بهره‌برداری است.

 

بیانیه اصول یا مانیفست FHIR

تیم FHIR یک بیانیه اصول (Manifesto) را پذیرفته است که اهداف و اولویت‌های پروژه FHIR را اعلام می‌کند:

• تمرکز بر پیاده‌سازان (Implementers)
• هدف‌گذاری برای پشتیبانی از سناریوهای رایج
• بهره‌گیری از فناوری‌های وب میان‌صنعتی
• الزام به خوانایی انسانی به‌عنوان سطح پایه هم‌کنش‌پذیری
• فراهم‌سازی آزادانه محتوا
• پشتیبانی از پارادایم‌ها و معماری‌های متعدد

تمرکز بر پیاده‌سازان

مشخصات FHIR برای پیاده‌سازان نوشته شده است؛ این مشخصات یک تمرین نظری در توسعه استانداردها نیست. پیاده‌سازان شامل توسعه‌دهندگان، تحلیلگران سامانه، متخصصان انفورماتیک و هر فردی هستند که در عملیاتی‌کردن سامانه‌ها نقش دارد.

تیم FHIR تلاش فراوانی می‌کند تا آنچه برای این گروه هدف اهمیت دارد را در اولویت قرار دهد و مباحث نظری پیچیده و لایه‌های انتزاعی ساختار را در سایر منابع (برای مثال صفحاتFHIR Confluence) نگه دارد.

هدف‌گذاری برای پشتیبانی از سناریوهای رایج

رویکرد حاکم بر تیم FHIR این است که کارهای رایج و متداولی که همه انجام می‌دهند باید آسان باشند، در حالی که موارد خاص و نیازمندی‌های پیچیده می‌توانند دشوارتر باشند. این موضوع بیشتر یک هدف است تا نتیجه‌ای که بتوان آن را اندازه‌گیری کرد و نحوه دستیابی به آن همچنان موضوع بحث و گفت‌وگوی مستمر در سراسر پروژه FHIR است.

بهره‌گیری از فناوری‌های وب میان‌صنعتی

هدف پروژه FHIR این است که تا حد امکان از فناوری‌های وب استفاده کند. برخی از این فناوری‌ها عبارت‌اند از:

XML، JSON، RESTful APIs، XHTML، KML، OAuth  و SCIM.

در مواردی که تحلیل نیازمندی‌ها یا محدودیت‌های معماری مانع استفاده از فناوری‌های موجود شوند، پروژه FHIR نگاشت‌هایی به محتوای مرتبط فراهم می‌کند.

الزام به خوانایی انسانی به‌عنوان سطح پایه هم‌کنش‌پذیری

مهم‌ترین نمود این اصل آن است که تمامی منابع می‌توانند -و همان‌گونه که پیش‌تر بحث شد، باید- دارای یک نمایش روایی قابل خواندن برای انسان باشند.

فراهم‌سازی آزادانه محتوا

تیم FHIR در پی آن است که محتوا را به‌صورت آزاد در دسترس قرار دهد. خود مشخصات FHIR تحت آزادترین مجوز ممکن منتشر شده است: Creative Commons Public Domain. این مجوز هر نوع استفاده مجدد را مجاز می‌داند و یکی از مهم‌ترین دلایل محبوبیت مشخصات FHIR به شمار می‌رود.

نرم‌افزارها، بازتفسیرهای ماشینی مشخصات، مشخصات مشتق‌شده، بازنشر بخش‌هایی از مشخصات و سایر کاربردهای مشابه همگی بر اساس این مجوز مجاز هستند. توجه داشته باشید که HL7 مالک علامت تجاری (Trademark) نام «FHIR» است و از آن به‌دقت محافظت می‌کند. پیاده‌سازان می‌توانند از واژه «FHIR» یا نماد شعله (Flame Icon) در محصولات خود (برای مثال در نام کتابخانه‌ها، وب‌سایت‌ها یا مطالب بازاریابی) استفاده کنند، اما برای این کار نیازمند دریافت مجوز کتبی هستند. البته برای اشاره به خود مشخصات FHIR نیازی به مجوز کتبی وجود ندارد؛ این الزام تنها زمانی مطرح می‌شود که FHIR بخشی از نام محصول یا خدمت شما باشد.

فراتر از این موارد، هدف تیم FHIR آن است که هم‌کنش‌پذیری را آن‌قدر کم‌هزینه کند که به یک کالای عمومی (Commodity) تبدیل شود و کاربران بالینی و کسب‌وکاری بدیهی بدانند که اطلاعات موردنیازشان هر زمان و هر مکان که بخواهند در دسترس آنان قرار خواهد گرفت.

پشتیبانی از پارادایم‌ها و معماری‌های متعدد

مشهودترین بخش مشخصات FHIR، رابط برنامه‌نویسی کاربردی RESTful است. این بخش کانون توجه بسیاری از پیاده‌سازان است، اما دامنه موارد کاربرد تبادل داده در حوزه سلامت گسترده‌تر از مسائلی است که صرفاً با معماری RESTful قابل حل باشند.

به دلایل مختلف معماری، سامانه‌های میراثی (Legacy Systems) و الزامات گردش‌کار،RESTful  تنها راه‌حل موجود نیست و حتی برای همه مسائل بهترین راه‌حل نیز محسوب نمی‌شود. تیم FHIR متعهد است اطمینان حاصل کند که محتوای FHIR علاوه بر APIهای RESTful، از طریق اسناد (Documents)، پیام‌ها (Messages) و خدمات (Services) نیز قابل اشتراک‌گذاری باشد.

 

توسعه FHIR

توسعه چابک (Agile Development)

FHIR از یک فرایند توسعه مشخصات مبتنی بر رویکرد چابک (Agile) استفاده می‌کند. این رویکرد از جامعه برنامه‌نویسی چابک اقتباس شده است که مجموعه‌ای از روش‌های توسعه نرم‌افزار را به کار می‌گیرد. بیانیه چابک (Agile Manifesto) بر دوازده اصل زیر استوار است:

 

1. رضایت مشتری از طریق ارائه زودهنگام و مستمر نرم‌افزار ارزشمند.
2. استقبال از تغییر نیازمندی‌ها، حتی در مراحل پایانی توسعه.
3. تحویل مکرر نرم‌افزار عملیاتی (در مقیاس هفته‌ها به جای ماه‌ها).
4. همکاری نزدیک و روزانه میان متخصصان کسب‌وکار و توسعه‌دهندگان.
5. شکل‌گیری پروژه‌ها حول افراد باانگیزه که باید به آنان اعتماد شود.
6. گفت‌وگوی رودررو بهترین شیوه ارتباط است.
7. نرم‌افزار عملیاتی، معیار اصلی سنجش پیشرفت است.
8. توسعه پایدار با توانایی حفظ سرعتی ثابت.
9. توجه مستمر به تعالی فنی و طراحی مناسب.
10. سادگی -هنر به حداکثر رساندن میزان کاری که انجام نمی‌شود- امری ضروری است.
11. تیم‌های خودسازمان‌ده.
12. انطباق منظم با شرایط در حال تغییر.

 

جامعه FHIR تلاش می‌کند مشخصات خود را بر اساس اصولی معادل این اصول توسعه دهد، البته در چارچوب محدودیت‌هایی که ساختارهای حاکم بر جامعه بر آن تحمیل می‌کنند. بخشی کلیدی از فرایند FHIR شامل انتشارهای مکرر، پذیرش تغییر نیازمندی‌ها و انطباق با شرایط متغیر است. از آنجا که FHIR یک استاندارد عملیاتی است و نه یک پروژه نرم‌افزاری، سرعت تغییرات آن به‌طور قابل‌توجهی کمتر از چرخه‌های متداول توسعه نرم‌افزار چابک است. همچنین با تبدیل شدن FHIR به یک استاندارد بین‌المللی مهم، روند پیشرفت آن به‌ناچار کندتر شده است. با این وجود، نرخ تغییرات در مشخصات FHIR، یا حتی صرفِ در حال تغییر بودن آن، همچنان چالشی مداوم برای بخش‌هایی از جامعه FHIR است که نیاز دارند به یک راهکار یکپارچه‌سازی مشخص متعهد شوند. هر پروژه در نهایت باید یک نسخه مشخص را انتخاب کند، در حالی که آگاه است تغییرات بیشتری در آینده رخ خواهند داد؛ تغییراتی که حتی ممکن است در پاسخ به مسائل مطرح‌شده توسط همان پروژه ایجاد شوند.

با مشاهده تکامل مشخصات FHIR در طول زمان، فرایند مشخصی در خصوص معرفی، توسعه و تثبیت بخش‌های مختلف استاندارد قابل مشاهده است. هنگامی که مفاهیم و یا نیازمندی‌های جدید برای نخستین بار معرفی می‌شوند، معمولاً ساده‌انگارانه هستند و پیچیدگی‌های واقعی مسئله را نادیده می‌گیرند؛ بنابراین انتظار می‌رود تغییرات قابل‌توجهی در آن‌ها رخ دهد. در واقع، این اتفاق همواره در جریان آزمون و تجربه ایده‌ها توسط جامعه رخ می‌دهد.

به مرور زمان، طراحی بر اساس تجربیات به‌دست‌آمده پالایش و اصلاح می‌شود. در طی این فرایند، تعداد بیشتری از سامانه‌ها طراحی در حال تکامل را در قالب نمونه‌های اولیه و سپس سامانه‌های عملیاتی پیاده‌سازی می‌کنند و در نتیجه اعمال تغییرات به‌تدریج پرهزینه‌تر می‌شود. این فرایند را می‌توان به‌راحتی با الگوی شناخته‌شده پویایی گروهی شامل مراحل «شکل‌گیری (Forming)، طوفان‌زایی (Storming)، هنجارسازی  (Norming) و عملکرد (Performing)» در مدل توسعه گروهی تاکمن مقایسه کرد.

چالش ناشی از این وضعیت برای پیاده‌سازان دو جنبه دارد:

1. بخش‌های مختلف مشخصات این فرایند را با زمان‌بندی‌های متفاوت طی می‌کنند.
2. تعیین اینکه یک مصنوع (Artefact) در کدام مرحله از این فرایند قرار دارد دشوار است، مگر آنکه فرد به‌طور عمیق در کل فرایند توسعه FHIR مشارکت داشته باشد.

 

مدل بلوغ FHIR

به همین دلیل، مشخصات FHIR برای مصنوعات قابل پیاده‌سازی، به‌صراحت یک سطح از مدل بلوغ FHIR (FMM) را مشخص می‌کند. مصنوعات پیاده‌سازی شامل مواردی هستند که یک پیاده‌سازی می‌تواند با آن‌ها منطبق شود؛ از جمله انواع داده (Data Types)، منابع (Resources) ، APIهای RESTful، قالب‌های XML و JSON و سایر اجزای مشابه.

مدل بلوغ FHIR یا FMM مجموعه‌ای رسمی از معیارها است که نشان می‌دهد یک مصنوع مشخص در چه مرحله‌ای از چرخه عمر خود قرار دارد. سطوح FMM بر اساس نظام شناخته‌شده CMM یا Capability Maturity Model طراحی شده‌اند. پیاده‌سازان می‌توانند از سطح FMM برای ارزیابی میزان بلوغ و پایداری یک منبع یا مصنوع استفاده کنند.

سطوح زیر برای FMM تعریف شده‌اند:

FMM0: منبع یا پروفایل (مصنوع) در نسخه ساخت جاری (Current Build) منتشر شده است، اما موجودیت آن، دامنه کلی و طراحی آن همچنان موضوع بحث و بررسی در کمیته‌های تخصصی است.

FMM1: علاوه بر الزامات FMM0:

• مصنوع در فرایند ساخت هیچ هشدار (Warning) ایجاد نمی‌کند.
• گروه کاری مسئول  (WG) اعلام کرده است که این مصنوع را تا حد زیادی کامل دانسته و آن را برای پیاده‌سازی آماده می‌داند.

FMM2: علاوه بر الزامات FMM1:

• مصنوع مورد آزمون قرار گرفته است.
• تبادل موفق آن میان حداقل سه سامانه مستقل که به‌طور جداگانه توسعه یافته‌اند، در یک Connectathon انجام شده است.
• نتایج این آزمون به گروه مدیریت FHIR (FHIR Management Group) گزارش شده است.

FMM3

علاوه بر الزامات FMM2:

• گروه کاری مسئول تأیید کرده است که مصنوع الزامات «راهنمای کیفیت DSTU» را برآورده می‌کند.
• مصنوع حداقل یک دوره رأی‌گیری رسمی (Formal Balloting) را پشت سر گذاشته است.
• در این رأی‌گیری حداقل 10 نظر از پیاده‌سازان متعلق به حداقل 3 سازمان مختلف دریافت شده است.
• این بازخوردها منجر به حداقل یک تغییر اساسی (Substantive Change) در مصنوع شده‌اند.

FMM4

علاوه بر الزامات FMM3:

• مصنوع در سراسر دامنه کاربرد خود (مطابق توضیحات بعدی) مورد آزمون قرار گرفته است.
• در یک انتشار رسمی (برای مثالDSTU) منتشر شده است.
• در چندین پروژه نمونه اولیه یا  Prototypeپیاده‌سازی شده است.
• همچنین گروه کاری مسئول توافق دارد که این منبع به اندازه کافی پایدار است که هرگونه تغییر ناسازگار با نسخه‌های قبلی بعبارتی Non-Backward Compatible Changes در آینده، نیازمند اجماع پیاده‌سازان باشد.

FMM5

علاوه بر الزامات FMM4:

• مصنوع در دو چرخه انتشار رسمی و در سطح FMM1 یا بالاتر (یعنی در سطحDSTU) منتشر شده است.
• در حداقل پنج سامانه عملیاتی مستقل (Independent Production Systems) پیاده‌سازی شده است.
• این پیاده‌سازی‌ها در بیش از یک کشور انجام شده‌اند.

پیاده‌سازان می‌توانند از سطح بلوغ تخصیص‌یافته استفاده کنند تا تشخیص دهند یک مصنوع مشخص در چه مرحله‌ای از فرایند کلی توسعه قرار دارد؛ هرچه سطح بالاتر باشد، آن مصنوع پایدارتر محسوب می‌شود. در سطوح بالاتر،HL7  برنامه دارد فرایند رسمی مشاوره‌ای با ذی‌نفعانی که به‌عنوان پیاده‌ساز آن مصنوع ثبت شده‌اند برقرار کند، هرچند جزئیات دقیق این فرایند هنوز نهایی نشده است.

فراتر از سطح FMM5، وضعیتNormative  قرار دارد. در این مرحله، یک مصنوع «منجمد یا Frozen» اعلام می‌شود؛ به این معنا که تغییرات آینده موجب اختلال در پیاده‌سازی‌های موجود نخواهند شد.

مهم‌ترین جنبه مدل بلوغ FHIR این است که تعریف موفقیت -یعنی تکمیل توسعه یک منبع- بسیار فراتر از صرف انتشار آن است. این تعریف ایجاب می‌کند که جامعه FHIR تمرکز خود را بر موفقیت پیاده‌سازی مشخصات معطوف کند. این موضوع ملموس‌ترین و عینی‌ترین نمود تمرکز پروژه FHIR بر پیاده‌سازی عملی است.Bottom of Form