सीमापार EHR इंटिग्रेशनमधून मिळालेले ५ धडे
मी दोन वेगवेगळ्या देशांमधील रुग्णांचे रेकॉर्ड्स जोडण्यासाठी अनेक महिने खर्च केले. मी दहा वर्षांचा क्लिनिकल अनुभव असलेल्या एका लीड बिझनेस अनालिस्टसोबत (Lead Business Analyst) काम केले. त्यांच्या दृष्टिकोनामुळे आरोग्यसेवा सॉफ्टवेअरकडे पाहण्याचा माझा दृष्टिकोन बदलला.
त्या प्रकल्पातून मिळालेले पाच धडे खालीलप्रमाणे आहेत.
- टर्मिनोलॉजी मॅपिंग (Terminology mapping) हे डेटा मॅपिंगपेक्षा कठीण आहे
इंजिनिअर्स अनेकदा इंटिग्रेशनकडे केवळ एक स्कीमा (schema) समस्या म्हणून पाहतात. तुम्ही फील्ड A ला फील्ड B शी मॅप करता आणि काम संपले असे समजता. आरोग्यसेवेमध्ये ही पद्धत अपयशी ठरते.
एका सिस्टममध्ये ICD-10 वापरले जात होते तर दुसऱ्यामध्ये ICD-11. त्यांचे मॅपिंग सहजपणे होऊ शकत नाही. एका सिस्टममध्ये लॅबसाठी LOINC वापरले जात होते, तर दुसरी सिस्टम जुने अंतर्गत कोड (internal codes) वापरत होती.
आम्ही कोड लिहिण्यापूर्वी आमच्या BA ने एक 'कॉन्सेप्ट क्रॉसवॉक' (concept crosswalk) तयार केला. त्यांनी स्थानिक कोड्सना SNOMED CT सारख्या मानक संचाशी (standard set) मॅप केले. याशिवाय, क्लिनिकल अर्थांमध्ये त्रुटी निर्माण झाली असती.
चुकीच्या फील्ड मॅपिंगमुळे चुकीची मूल्ये (values) तयार होतात. परंतु, चुकीच्या टर्मिनोलॉजी मॅपिंगमुळे अशी मूल्ये तयार होतात जी वरवर पाहता योग्य वाटतात पण क्लिनिकलदृष्ट्या चुकीची असतात. दुसरी गोष्ट अधिक धोकादायक आहे.
- डेटा कायदे सुरुवातीच्या टप्प्यातच आर्किटेक्चरला आकार देतात
मला वाटले होते की आपण आधी डेटा मॉडेल डिझाइन करू आणि कॉम्प्लायन्स (compliance) नंतर हाताळू. मी चुकत होतो.
सीमापार जाणारा रुग्णांचा डेटा HIPAA किंवा GDPR सारख्या अनेक कायद्यांच्या कक्षेत येतो. काही देश आरोग्य डेटा त्यांच्या सीमाबाहेर नेण्यास मनाई करतात.
आमच्या BA ने सुरुवातीलाच कायदेशीर टीमसोबत काम केले. कोणते फील्ड्स रेप्लिकेट (replicate) केले जाऊ शकतात आणि कोणत्या फील्ड्सचे 'डी-आयडेंटिफिकेशन' (de-identification) करणे आवश्यक आहे, याचा निर्णय त्यांनी घेतला.
यामुळे आमचे आर्किटेक्चर बदलले. आम्ही एका सिंगल रेप्लिकेटेड डेटाबेसऐवजी 'फेडरेटेड क्वेरी लेयर' (federated query layer) तयार केला. आम्ही आमच्या स्कीमामध्ये थेट डेटा क्लासिफिकेशन टॅग्स जोडले.
डेटा मॉडेल डिझाइन करण्यापूर्वी कॉम्प्लायन्स तज्ज्ञ आणि BA ला चर्चेत सामील करून घ्या.
- मानके (Standards) पुरेशी नाहीत
दोन्ही सिस्टम्स HL7 ला सपोर्ट करत होत्या. मात्र, एक HL7 v2 वापरत होती आणि दुसरी FHIR R4. ट्रान्सलेशन लेयरशिवाय त्या एकमेकांशी संवाद साधू शकत नव्हत्या.
FHIR मध्ये देखील आम्हाला प्रोफाईल मिसमॅचचा (profile mismatches) सामना करावा लागला. दोन्ही सिस्टम्स कॉम्प्लायन्सचा दावा करत होत्या, परंतु त्यांनी वेगळे इम्प्लिमेंटेशन गाइड्स (implementation guides) वापरले होते.
एखादी सिस्टम एखाद्या मानकाला (standard) सपोर्ट करते म्हणून इंटिग्रेशन सोपे असेल असे समजू नका. नेहमी विशिष्ट व्हर्जन आणि प्रोफाईलबद्दल विचारा. अॅडॉप्टर लेयरसाठी (adapter layer) वेळ राखून ठेवा.
- वर्कफ्लो डायग्राम्स लपलेले एज केसेस (edge cases) शोधून काढतात
मी वर्कफ्लो डायग्राम्सकडे केवळ अतिरिक्त डॉक्युमेंटेशन म्हणून पाहायचो. मी चुकत होतो.
आमच्या BA ने पेशंट ट्रान्सफरचे सविस्तर मॅपिंग केले. उपचार सुरू असताना रुग्ण हलवला गेल्यास किंवा डिस्चार्ज मिळाल्यानंतर लॅब रिपोर्ट आल्यास काय होते, याचा त्यांनी विचार केला.
हॉस्पिटलमध्ये या केवळ एज केसेस नसून त्या दररोज घडणाऱ्या गोष्टी आहेत.
या डायग्राम्समुळे आमचे डेटा मॉडेल बदलले. दोन्ही सिस्टम्समध्ये सलग उपचारांचा मागोवा घेण्यासाठी आम्ही 'केअर एपिसोड' (care episode) ही संकल्पना जोडली.
- सुरुवातीलाच एक सामायिक शब्दकोश (shared glossary) तयार करा
'Encounter' किंवा 'Discharge' सारख्या शब्दांचे अर्थ वेगवेगळ्या सिस्टममध्ये वेगवेगळे असू शकतात. टीम्सनी शब्दांचा अर्थ वेगवेगळा काढल्यामुळे आमचा वेळ वाया गेला.
आमच्या BA ने एक सामायिक शब्दकोश तयार केला. प्रत्येक स्टेकहोल्डरने (stakeholder) या व्याख्यांचे पुनरावलोकन केले आणि त्या मान्य केल्या. आम्ही प्रत्येक गरजेमध्ये (requirement) या दस्तऐवजाचा संदर्भ दिला.
प्रत्येक डोमेन टर्म (domain term) संदिग्ध असू शकते असे समजा. दोन्ही बाजूंनी स्वाक्षरी केलेल्या दस्तऐवजात त्याची व्याख्या करा.
Summary
एक सक्षम BA केवळ 'तिकिट्स' (tickets) लिहित नाही. ते नियामक निर्बंध (regulatory constraints) आणि क्लिनिकल अर्थासाठी आर्किटेक्ट म्हणून काम करतात. जर तुम्ही जटिल सॉफ्टवेअर बनवत असाल, तर या भूमिकेला अतिरिक्त ओझे (overhead) समजू नका. हे तांत्रिक यश क्लिनिकल अपयशात बदलण्यापासून वाचवते.
Optional learning community: https://t.me/GyaanSetuAi