సరిహద్దుల మధ్య EHR ఇంటిగ్రేషన్ నుండి నేర్చుకున్న 5 విషయాలు
రెండు వేర్వేరు దేశాల మధ్య రోగుల రికార్డులను అనుసంధానించడానికి నేను నెలల తరబడి సమయం వెచ్చించాను. పదేళ్ల క్లినికల్ అనుభవం ఉన్న లీడ్ బిజినెస్ అనలిస్ట్తో నేను కలిసి పనిచేశాను. ఆమె విధానం హెల్త్కేర్ సాఫ్ట్వేర్ను నేను చూసే దృక్పథాన్ని మార్చేసింది.
ఆ ప్రాజెక్ట్ నుండి నేర్చుకున్న ఐదు పాఠాలు ఇక్కడ ఉన్నాయి.
- టెర్మినాలజీ మ్యాపింగ్, డేటా మ్యాపింగ్ కంటే కష్టమైనది
ఇంజనీర్లు తరచుగా ఇంటిగ్రేషన్ను ఒక స్కీమా సమస్యగా పరిగణిస్తారు. మీరు ఫీల్డ్ A ని ఫీల్డ్ B కి మ్యాప్ చేసి పని పూర్తి చేస్తారు. హెల్త్కేర్లో ఇది విఫలమవుతుంది.
ఒక సిస్టమ్ ICD-10 ని, మరొకటి ICD-11 ని ఉపయోగించింది. అవి నేరుగా మ్యాప్ అవ్వవు. ఒక సిస్టమ్ ల్యాబ్స్ కోసం LOINC ని ఉపయోగించగా, మరొకటి పాత ఇంటర్నల్ కోడ్లను ఉపయోగించింది.
మేము కోడ్ రాయకముందే మా BA ఒక కాన్సెప్ట్ క్రాస్వాక్ (concept crosswalk) రూపొందించారు. ఆమె లోకల్ కోడ్లను SNOMED CT వంటి ప్రామాణిక సెట్లకు మ్యాప్ చేశారు. ఇది లేకపోతే, క్లినికల్ అర్థం దెబ్బతినేది.
తప్పుగా ఉన్న ఫీల్డ్ మ్యాపింగ్ తప్పుడు విలువలను సృష్టిస్తుంది. తప్పుగా ఉన్న టెర్మినాలజీ మ్యాపింగ్, నమ్మదగినవిగా అనిపించే కానీ క్లినికల్ పరంగా తప్పుగా ఉండే విలువలను సృష్టిస్తుంది. రెండవది చాలా ప్రమాదకరమైనది.
- డేటా చట్టాలు ప్రారంభ దశలోనే ఆర్కిటెక్చర్ను ప్రభావితం చేస్తాయి
మొదట డేటా మోడల్ను డిజైన్ చేసి, తర్వాత కంప్లయన్స్ (compliance) చూసుకుంటామని నేను అనుకున్నాను. కానీ నేను పొరబడ్డాను.
సరిహద్దులు దాటే రోగి డేటా HIPAA లేదా GDPR వంటి అనేక చట్టాలకు లోబడి ఉంటుంది. కొన్ని దేశాలు ఆరోగ్య డేటా తమ సరిహద్దులు దాటడాన్ని నిషేధిస్తాయి.
మా BA ప్రారంభ దశలోనే లీగల్ టీమ్స్తో కలిసి పనిచేశారు. ఏ ఫీల్డ్లను రెప్లికేట్ చేయవచ్చు మరియు ఏవి డీ-ఐడెంటిఫికేషన్ (de-identification) చేయాల్సి ఉంటుందో ఆమె నిర్ణయించారు.
ఇది మా ఆర్కిటెక్చర్ను మార్చేసింది. మేము ఒకే రిప్లికేటెడ్ డేటాబేస్కు బదులుగా ఫెడరేటెడ్ క్వెరీ లేయర్ను (federated query layer) నిర్మించాము. మా స్కీమాలోకి నేరుగా డేటా క్లాసిఫికేషన్ ట్యాగ్లను జోడించాము.
మీరు మీ డేటా మోడల్ను డిజైన్ చేసే ముందే కంప్లయన్స్ నిపుణులను మరియు ఒక BA ని సంప్రదించండి.
- ప్రమాణాలు మాత్రమే సరిపోవు
రెండు సిస్టమ్లు HL7 ని సపోర్ట్ చేశాయి. అయితే, ఒకటి HL7 v2 ని, మరొకటి FHIR R4 ని ఉపయోగించాయి. ట్రాన్స్లేషన్ లేయర్ లేకుండా అవి ఒకదానితో ఒకటి మాట్లాడుకోలేవు.
FHIR లో కూడా, మేము ప్రొఫైల్ మిస్మ్యాచ్లను ఎదుర్కొన్నాము. రెండు సిస్టమ్లు కంప్లయన్స్ ఉన్నాయని పేర్కొన్నప్పటికీ, వేర్వేరు ఇంప్లిమెంటేషన్ గైడ్లను ఉపయోగించాయి.
ఒక సిస్టమ్ ప్రమాణాన్ని సపోర్ట్ చేస్తోందన్నంత మాత్రాన ఇంటిగ్రేషన్ సులభం అని అనుకోవద్దు. ఎల్లప్పుడూ నిర్దిష్ట వెర్షన్ మరియు ప్రొఫైల్ గురించి అడగండి. అడాప్టర్ లేయర్ (adapter layer) కోసం సమయాన్ని కేటాయించండి.
- వర్క్ఫ్లో డయాగ్రామ్లు దాగి ఉన్న ఎడ్జ్ కేస్లను గుర్తిస్తాయి
నేను వర్క్ఫ్లో డయాగ్రామ్లను అదనపు డాక్యుమెంటేషన్గా చూసేవాడిని. కానీ నేను పొరబడ్డాను.
మా BA రోగుల బదిలీలను వివరంగా మ్యాప్ చేశారు. చికిత్స మధ్యలో రోగి మారినప్పుడు లేదా డిశ్చార్జ్ అయిన తర్వాత ల్యాబ్ రిజల్ట్ వచ్చినప్పుడు ఏం జరుగుతుందో ఆమె పరిశీలించారు.
ఇవి ఆసుపత్రిలో ఎడ్జ్ కేస్లు కావు. ఇవి ప్రతిరోజూ జరుగుతుంటాయి.
ఈ డయాగ్రామ్లు మా డేటా మోడల్ను మార్చాయి. రెండు సిస్టమ్ల మధ్య నిరంతర సంరక్షణను ట్రాక్ చేయడానికి మేము 'కేర్ ఎపిసోడ్' (care episode) అనే కాన్సెప్ట్ను జోడించాము.
- ప్రారంభంలోనే ఒక ఉమ్మడి గ్లోసరీని రూపొందించండి
encounter లేదా discharge వంటి పదాలకు వేర్వేరు సిస్టమ్లలో వేర్వేరు అర్థాలు ఉంటాయి. టీమ్లు పదాలను భిన్నంగా అర్థం చేసుకోవడం వల్ల మేము సమయాన్ని వృధా చేశాము.
మా BA ఒక ఉమ్మడి గ్లోసరీని రూపొందించారు. ప్రతి స్టేక్హోల్డర్ ఈ నిర్వచనాలను సమీక్షించి అంగీకరించారు. మేము ప్రతి అవసరంలో (requirement) ఈ పత్రాన్ని రిఫరెన్స్గా తీసుకున్నాము.
ప్రతి డొమైన్ పదం అస్పష్టంగా ఉంటుందని భావించండి. ఇరు పక్షాలు సంతకం చేసే పత్రంలో దానిని నిర్వచించండి.
సారాంశం
ఒక బలమైన BA కేవలం టికెట్లు రాయడమే కాకుండా అంతకంటే ఎక్కువ చేస్తారు. వారు రెగ్యులేటరీ పరిమితులు మరియు క్లినికల్ అర్థం కోసం ఆర్కిటెక్ట్లుగా వ్యవహరిస్తారు. మీరు సంక్లిష్టమైన సాఫ్ట్వేర్ను నిర్మిస్తుంటే, ఈ పాత్రను అదనపు భారం (overhead) గా చూడకండి. ఇది సాంకేతిక విజయం క్లినికల్ వైఫల్యంగా మారకుండా నిరోధిస్తుంది.
ఐచ్ఛిక లెర్నింగ్ కమ్యూనిటీ: https://t.me/GyaanSetuAi