একটি আন্তঃসীমান্ত EHR ইন্টিগ্রেশন থেকে প্রাপ্ত ৫টি শিক্ষা
আমি দুই ভিন্ন দেশের মধ্যে রোগীর রেকর্ড সংযুক্ত করার কাজে কয়েক মাস ব্যয় করেছি। আমি দশ বছরের ক্লিনিক্যাল অভিজ্ঞতা সম্পন্ন একজন লিড বিজনেস অ্যানালিস্টের (Lead Business Analyst) সাথে কাজ করেছি। তাঁর দৃষ্টিভঙ্গি স্বাস্থ্যসেবা সফটওয়্যার সম্পর্কে আমার ধারণা বদলে দিয়েছে।
সেই প্রজেক্ট থেকে প্রাপ্ত পাঁচটি শিক্ষা নিচে দেওয়া হলো।
১. ডেটা ম্যাপিংয়ের চেয়ে টার্মিনোলজি ম্যাপিং করা বেশি কঠিন
ইঞ্জিনিয়াররা প্রায়শই ইন্টিগ্রেশনকে একটি স্কিমা (schema) সমস্যা হিসেবে দেখেন। আপনি ফিল্ড A-কে ফিল্ড B-এর সাথে ম্যাপ করবেন এবং কাজ শেষ। স্বাস্থ্যসেবার ক্ষেত্রে এটি কাজ করে না।
একটি সিস্টেম ICD-10 ব্যবহার করত এবং অন্যটি ICD-11 ব্যবহার করত। এগুলো খুব সহজে ম্যাপ করা যায় না। একটি সিস্টেম ল্যাবের জন্য LOINC ব্যবহার করত, যেখানে অন্যটি পুরনো অভ্যন্তরীণ কোড ব্যবহার করত।
কোড লেখার আগেই আমাদের BA একটি 'কনসেপ্ট ক্রসওয়াক' (concept crosswalk) তৈরি করেছিলেন। তিনি স্থানীয় কোডগুলোকে SNOMED CT-এর মতো একটি স্ট্যান্ডার্ড সেটের সাথে ম্যাপ করেছিলেন। এটি ছাড়া ক্লিনিক্যাল অর্থ বা গুরুত্ব নষ্ট হয়ে যেত।
ভুল ফিল্ড ম্যাপিং ভুল মান (value) তৈরি করে। কিন্তু ভুল টার্মিনোলজি ম্যাপিং এমন মান তৈরি করে যা দেখতে সঠিক মনে হলেও ক্লিনিক্যালি ভুল। শেষেরটি অনেক বেশি বিপজ্জনক।
২. ডেটা আইন আর্কিটেকচারকে শুরুতেই প্রভাবিত করে
আমি ভেবেছিলাম আমরা প্রথমে ডেটা মডেল ডিজাইন করব এবং পরে কমপ্লায়েন্স (compliance) বা আইনি বাধ্যবাধকতা সামলাব। আমি ভুল ছিলাম।
সীমানা ছাড়িয়ে রোগীর ডেটা আদান-প্রদান করার ক্ষেত্রে HIPAA বা GDPR-এর মতো একাধিক আইন প্রযোজ্য হয়। কিছু দেশ স্বাস্থ্য সংক্রান্ত ডেটা তাদের সীমানার বাইরে পাঠানো নিষিদ্ধ করেছে।
আমাদের BA শুরুতেই আইনি দলগুলোর সাথে কাজ করেছিলেন। তিনি সিদ্ধান্ত নিয়েছিলেন কোন ফিল্ডগুলো রেপ্লিকেট (replicate) করা যাবে এবং কোনগুলোর ডি-আইডেন্টিফিকেশন (de-identification) প্রয়োজন।
এটি আমাদের আর্কিটেকচার বদলে দিয়েছে। আমরা একটি একক রেপ্লিকেটেড ডেটাবেসের পরিবর্তে একটি ফেডারেটেড কুয়েরি লেয়ার (federated query layer) তৈরি করেছি। আমরা সরাসরি আমাদের স্কিমার মধ্যে ডেটা ক্লাসিফিকেশন ট্যাগ যুক্ত করেছি।
ডেটা মডেল ডিজাইন করার আগেই কমপ্লায়েন্স বিশেষজ্ঞ এবং একজন BA-কে সাথে রাখুন।
৩. স্ট্যান্ডার্ড বা মানদণ্ডই যথেষ্ট নয়
উভয় সিস্টেমই HL7 সমর্থন করত। তবে, একটি HL7 v2 ব্যবহার করত এবং অন্যটি FHIR R4 ব্যবহার করত। একটি ট্রান্সলেশন লেয়ার ছাড়া তাদের মধ্যে যোগাযোগ সম্ভব ছিল না।
এমনকি FHIR-এর মধ্যেও আমরা প্রোফাইল মিসম্যাচ (profile mismatch) বা অমিল দেখতে পেয়েছি। উভয় সিস্টেমই কমপ্লায়েন্সের দাবি করলেও তারা ভিন্ন ভিন্ন ইমপ্লিমেন্টেশন গাইড ব্যবহার করছিল।
একটি সিস্টেম কোনো স্ট্যান্ডার্ড সমর্থন করে বলেই ইন্টিগ্রেশন সহজ হবে বলে ধরে নেবেন না। সর্বদা নির্দিষ্ট ভার্সন এবং প্রোফাইল সম্পর্কে জিজ্ঞাসা করুন। একটি অ্যাডাপ্টার লেয়ারের (adapter layer) জন্য সময় বরাদ্দ রাখুন।
৪. ওয়ার্কফ্লো ডায়াগ্রাম লুকানো এজ কেসগুলো (edge cases) শনাক্ত করতে সাহায্য করে
আমি আগে ওয়ার্কফ্লো ডায়াগ্রামকে অতিরিক্ত ডকুমেন্টেশন হিসেবে দেখতাম। আমি ভুল ছিলাম।
আমাদের BA রোগীর স্থানান্তরের প্রক্রিয়াটি বিস্তারিতভাবে ম্যাপ করেছিলেন। তিনি লক্ষ্য করেছিলেন যে চিকিৎসা চলাকালীন রোগী স্থানান্তরিত হলে বা ডিসচার্জের পরে ল্যাব রিপোর্ট আসলে কী ঘটে।
একটি হাসপাতালে এগুলো কোনো 'এজ কেস' নয়; এগুলো প্রতিদিন ঘটে।
এই ডায়াগ্রামগুলো আমাদের ডেটা মডেল বদলে দিয়েছে। উভয় সিস্টেম জুড়ে নিরবচ্ছিন্ন সেবা ট্র্যাক করার জন্য আমরা একটি 'কেয়ার এপিসোড' (care episode) ধারণা যুক্ত করেছি।
৪. দ্রুত একটি সাধারণ গ্লসারি (glossary) তৈরি করুন
'encounter' বা 'discharge'-এর মতো শব্দগুলোর অর্থ বিভিন্ন সিস্টেমে ভিন্ন ভিন্ন হতে পারে। বিভিন্ন টিম শব্দগুলোকে ভিন্নভাবে ব্যাখ্যা করার কারণে আমাদের সময় নষ্ট হয়েছে।
আমাদের BA একটি সাধারণ গ্লসারি তৈরি করেছিলেন। প্রতিটি স্টেকহোল্ডার এই সংজ্ঞাগুলো পর্যালোচনা করেছিলেন এবং এতে সম্মত হয়েছিলেন। আমরা প্রতিটি রিকোয়ারমেন্টে এই ডকুমেন্টটি রেফারেন্স হিসেবে ব্যবহার করেছি।
ধরে নিন যে প্রতিটি ডোমেইন টার্ম বা শব্দ অস্পষ্ট হতে পারে। উভয় পক্ষ স্বাক্ষর করবে এমন একটি ডকুমেন্টে এর সংজ্ঞা নির্ধারণ করুন।
সারসংক্ষেপ
একজন দক্ষ BA শুধুমাত্র টিকিট লেখার কাজ করেন না। তাঁরা রেগুলেটরি সীমাবদ্ধতা এবং ক্লিনিক্যাল অর্থের ক্ষেত্রে আর্কিটেক্ট হিসেবে কাজ করেন। আপনি যদি জটিল সফটওয়্যার তৈরি করেন, তবে এই ভূমিকাকে অতিরিক্ত বোঝা (overhead) হিসেবে দেখবেন না। এটি প্রযুক্তিগত সাফল্যকে ক্লিনিক্যাল ব্যর্থতায় পরিণত হওয়া থেকে রক্ষা করে।
ঐচ্ছিক লার্নিং কমিউনিটি: https://t.me/GyaanSetuAi