ಅಂತರರಾಷ್ಟ್ರೀಯ EHR ಏಕೀಕರಣದಿಂದ ಕಲಿತ 5 ಪಾಠಗಳು
ನಾನು ಎರಡು ಬೇರೆ ಬೇರೆ ದೇಶಗಳ ನಡುವೆ ರೋಗಿಗಳ ದಾಖಲೆಗಳನ್ನು ಸಂಪರ್ಕಿಸಲು ತಿಂಗಳುಗಟ್ಟಲೆ ಸಮಯ ವ್ಯಯಿಸಿದೆ. ಹತ್ತು ವರ್ಷಗಳ ಕ್ಲಿನಿಕಲ್ ಅನುಭವವಿರುವ ಲೀಡ್ ಬಿಸಿನೆಸ್ ಅನಲಿಸ್ಟ್ (Lead Business Analyst) ಜೊತೆ ನಾನು ಕೆಲಸ ಮಾಡಿದೆ. ಅವರ ವಿಧಾನವು ಆರೋಗ್ಯ ರಕ್ಷಣಾ ಸಾಫ್ಟ್ವೇರ್ ಬಗ್ಗೆ ನನ್ನ ದೃಷ್ಟಿಕೋನವನ್ನೇ ಬದಲಿಸಿತು.
ಆ ಯೋಜನೆಯಿಂದ ಕಲಿತ ಐದು ಪಾಠಗಳು ಇಲ್ಲಿವೆ.
- ಡೇಟಾ ಮ್ಯಾಪಿಂಗ್ಗಿಂತ ಟರ್ಮಿನಾಲಜಿ ಮ್ಯಾಪಿಂಗ್ (Terminology mapping) ಹೆಚ್ಚು ಕಷ್ಟಕರವಾಗಿದೆ
ಎಂಜಿನಿಯರ್ಗಳು ಹೆಚ್ಚಾಗಿ ಏಕೀಕರಣವನ್ನು (integration) ಕೇವಲ ಒಂದು ಸ್ಕೀಮಾ (schema) ಸಮಸ್ಯೆಯೆಂದು ಪರಿಗಣಿಸುತ್ತಾರೆ. ನೀವು ಫೀಲ್ಡ್ A ಅನ್ನು ಫೀಲ್ಡ್ B ಗೆ ಮ್ಯಾಪ್ ಮಾಡಿ ಕೆಲಸ ಮುಗಿಸಿಬಿಡುತ್ತೀರಿ. ಆದರೆ ಆರೋಗ್ಯ ರಕ್ಷಣಾ ಕ್ಷೇತ್ರದಲ್ಲಿ ಇದು ವಿಫಲವಾಗುತ್ತದೆ.
ಒಂದು ವ್ಯವಸ್ಥೆಯು ICD-10 ಅನ್ನು ಬಳಸುತ್ತಿದ್ದರೆ, ಇನ್ನೊಂದು ICD-11 ಅನ್ನು ಬಳಸುತ್ತಿತ್ತು. ಇವುಗಳನ್ನು ಸುಲಭವಾಗಿ ಮ್ಯಾಪ್ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ. ಒಂದು ವ್ಯವಸ್ಥೆಯು ಲ್ಯಾಬ್ಗಳಿಗಾಗಿ LOINC ಅನ್ನು ಬಳಸುತ್ತಿದ್ದರೆ, ಇನ್ನೊಂದು ಹಳೆಯ ಆಂತರಿಕ ಕೋಡ್ಗಳನ್ನು ಬಳಸುತ್ತಿತ್ತು.
ನಾವು ಕೋಡ್ ಬರೆಯುವ ಮೊದಲೇ ನಮ್ಮ BA ಒಂದು 'ಕನ್ಸೆಪ್ಟ್ ಕ್ರಾಸ್ವಾಕ್' (concept crosswalk) ಅನ್ನು ಸಿದ್ಧಪಡಿಸಿದರು. ಅವರು ಸ್ಥಳೀಯ ಕೋಡ್ಗಳನ್ನು SNOMED CT ನಂತಹ ಪ್ರಮಾಣಿತ ಸೆಟ್ಗೆ ಮ್ಯಾಪ್ ಮಾಡಿದರು. ಇದು ಇಲ್ಲದಿದ್ದರೆ, ನಾವು ಕ್ಲಿನಿಕಲ್ ಅರ್ಥವನ್ನು ತಪ್ಪಾಗಿ ನೀಡುತ್ತಿದ್ದೆವು.
ತಪ್ಪಾದ ಫೀಲ್ಡ್ ಮ್ಯಾಪಿಂಗ್ ತಪ್ಪು ಮೌಲ್ಯಗಳನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ. ಆದರೆ ತಪ್ಪಾದ ಟರ್ಮಿನಾಲಜಿ ಮ್ಯಾಪಿಂಗ್, ನಂಬಲರ್ಹವಾಗಿ ಕಾಣುವ ಆದರೆ ಕ್ಲಿನಿಕಲ್ ಆಗಿ ತಪ್ಪು ಮೌಲ್ಯಗಳನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ. ಎರಡನೆಯದು ಹೆಚ್ಚು ಅಪಾಯಕಾರಿ.
- ಡೇಟಾ ಕಾನೂನುಗಳು ಆರಂಭದಲ್ಲೇ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ರೂಪಿಸುತ್ತವೆ
ನಾವು ಮೊದಲು ಡೇಟಾ ಮಾಡೆಲ್ ವಿನ್ಯಾಸಗೊಳಿಸಿ, ನಂತರ ಅನುಸರಣೆಯನ್ನು (compliance) ನಿರ್ವಹಿಸುತ್ತೇವೆ ಎಂದು ನಾನು ಭಾವಿಸಿದ್ದೆ. ನಾನು ತಪ್ಪು ಮಾಡಿದ್ದೆ.
ಗಡಿ ದಾಟುವ ರೋಗಿಗಳ ಡೇಟಾ HIPAA ಅಥವಾ GDPR ನಂತಹ ಹಲವಾರು ಕಾನೂನುಗಳಿಗೆ ಒಳಪಟ್ಟಿರುತ್ತದೆ. ಕೆಲವು ದೇಶಗಳು ಆರೋಗ್ಯ ಡೇಟಾ ತಮ್ಮ ಗಡಿಯಿಂದ ಹೊರಗೆ ಹೋಗುವುದನ್ನು ನಿಷೇಧಿಸುತ್ತವೆ.
ನಮ್ಮ BA ಆರಂಭದಲ್ಲೇ ಕಾನೂನು ತಂಡಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಿದರು. ಯಾವ ಫೀಲ್ಡ್ಗಳನ್ನು ನಕಲಿಸಬಹುದು (replicate) ಮತ್ತು ಯಾವವುಗಳನ್ನು ಡಿ-ಐಡೆಂಟಿಫಿಕೇಶನ್ (de-identification) ಮಾಡಬೇಕೆಂದು ಅವರು ನಿರ್ಧರಿಸಿದರು.
ಇದು ನಮ್ಮ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ಬದಲಿಸಿತು. ನಾವು ಒಂದೇ ಡೇಟಾಬೇಸ್ ಅನ್ನು ನಕಲು ಮಾಡುವ ಬದಲು ಫೆಡರೇಟೆಡ್ ಕ್ವೆರಿ ಲೇಯರ್ (federated query layer) ಅನ್ನು ನಿರ್ಮಿಸಿದೆವು. ನಾವು ನಮ್ಮ ಸ್ಕೀಮಾದಲ್ಲಿ ನೇರವಾಗಿ ಡೇಟಾ ವರ್ಗೀಕರಣ ಟ್ಯಾಗ್ಗಳನ್ನು (data classification tags) ಸೇರಿಸಿದೆವು.
ನೀವು ನಿಮ್ಮ ಡೇಟಾ ಮಾಡೆಲ್ ಅನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸುವ ಮೊದಲು ಅನುಸರಣೆ ತಜ್ಞರನ್ನು (compliance experts) ಮತ್ತು BA ಅನ್ನು ಒಳಗೊಳ್ಳಿ.
- ಪ್ರಮಾಣಿತಗಳು (Standards) ಸಾಕಾಗುವುದಿಲ್ಲ
ಎರಡೂ ವ್ಯವಸ್ಥೆಗಳು HL7 ಅನ್ನು ಬೆಂಬಲಿಸುತ್ತಿದ್ದವು. ಆದಾಗ್ಯೂ, ಒಂದು HL7 v2 ಅನ್ನು ಬಳಸುತ್ತಿದ್ದರೆ, ಇನ್ನೊಂದು FHIR R4 ಅನ್ನು ಬಳಸುತ್ತಿತ್ತು. ಅನುವಾದಕ ಲೇಯರ್ (translation layer) ಇಲ್ಲದೆ ಅವುಗಳ ನಡುವೆ ಸಂವಹನ ಸಾಧ್ಯವಾಗಲಿಲ್ಲ.
FHIR ಒಳಗೂ ಸಹ, ನಾವು ಪ್ರೊಫೈಲ್ ಅಸಮತೋಲನಗಳನ್ನು (profile mismatches) ಎದುರಿಸಿದೆವು. ಎರಡೂ ವ್ಯವಸ್ಥೆಗಳು ಅನುಸರಣೆಯನ್ನು ಹೊಂದಿವೆ ಎಂದು ಹೇಳಿಕೊಂಡರೂ, ವಿಭಿನ್ನ ಇಂಪ್ಲಿಮೆಂಟೇಶನ್ ಗೈಡ್ಗಳನ್ನು ಬಳಸುತ್ತಿದ್ದವು.
ಒಂದು ವ್ಯವಸ್ಥೆಯು ಪ್ರಮಾಣಿತವನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ ಎಂಬ ಕಾರಣಕ್ಕೆ ಏಕೀಕರಣ ಸುಲಭ ಎಂದು ಭಾವಿಸಬೇಡಿ. ಯಾವಾಗಲೂ ನಿರ್ದಿಷ್ಟ ಆವೃತ್ತಿ (version) ಮತ್ತು ಪ್ರೊಫೈಲ್ ಬಗ್ಗೆ ಕೇಳಿ. ಅಡಾಪ್ಟರ್ ಲೇಯರ್ (adapter layer) ಗಾಗಿ ಸಮಯವನ್ನು ಮೀಸಲಿಡಿ.
- ವರ್ಕ್ಫ್ಲೋ ಡಯಾಗ್ರಾಮ್ಗಳು (Workflow diagrams) ಅಡಗಿರುವ ಎಡ್ಜ್ ಕೇಸ್ಗಳನ್ನು (edge cases) ಪತ್ತೆಹಚ್ಚುತ್ತವೆ
ನಾನು ವರ್ಕ್ಫ್ಲೋ ಡಯಾಗ್ರಾಮ್ಗಳನ್ನು ಕೇವಲ ಹೆಚ್ಚುವರಿ ದಾಖಲೆ ಎಂದು ಭಾವಿಸುತ್ತಿದ್ದೆ. ನಾನು ತಪ್ಪು ಮಾಡಿದ್ದೆ.
ನಮ್ಮ BA ರೋಗಿಗಳ ವರ್ಗಾವಣೆಯನ್ನು ವಿವರವಾಗಿ ಮ್ಯಾಪ್ ಮಾಡಿದರು. ಚಿಕಿತ್ಸೆಯ ಮಧ್ಯದಲ್ಲಿ ರೋಗಿ ಬದಲಾದಾಗ ಅಥವಾ ಡಿಸ್ಚಾರ್ಜ್ ಆದ ನಂತರ ಲ್ಯಾಬ್ ವರದಿ ಬಂದಾಗ ಏನಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಅವರು ಗಮನಿಸಿದರು.
ಇವು ಆಸ್ಪತ್ರೆಯಲ್ಲಿ ಕೇವಲ ಅಪರೂಪದ ಘಟನೆಗಳಲ್ಲ (edge cases). ಇವು ಪ್ರತಿದಿನ ನಡೆಯುತ್ತವೆ.
ಈ ಡಯಾಗ್ರಾಮ್ಗಳು ನಮ್ಮ ಡೇಟಾ ಮಾಡೆಲ್ ಅನ್ನು ಬದಲಿಸಿದವು. ಎರಡೂ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ ನಿರಂತರ ಆರೈಕೆಯನ್ನು ಪತ್ತೆಹಚ್ಚಲು ನಾವು 'ಕೇರ್ ಎಪಿಸೋಡ್' (care episode) ಪರಿಕಲ್ಪನೆಯನ್ನು ಸೇರಿಸಿದೆವು.
- ಆರಂಭದಲ್ಲೇ ಒಂದು ಹಂಚಿಕೆಯ ಶಬ್ದಕೋಶವನ್ನು (shared glossary) ರೂಪಿಸಿ
encounter ಅಥವಾ discharge ನಂತಹ ಪದಗಳು ವಿಭಿನ್ನ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ ವಿಭಿನ್ನ ಅರ್ಥಗಳನ್ನು ನೀಡುತ್ತವೆ. ತಂಡಗಳು ಪದಗಳನ್ನು ವಿಭಿನ್ನವಾಗಿ ಅರ್ಥೈಸಿಕೊಂಡಿದ್ದರಿಂದ ನಾವು ಸಮಯ ವ್ಯರ್ಥ ಮಾಡಿದೆವು.
ನಮ್ಮ BA ಒಂದು ಹಂಚಿಕೆಯ ಶಬ್ದಕೋಶವನ್ನು ನಿರ್ಮಿಸಿದರು. ಪ್ರತಿಯೊಬ್ಬ ಪಾಲುದಾರರು (stakeholder) ಈ ವ್ಯಾಖ್ಯಾನಗಳನ್ನು ಪರಿಶೀಲಿಸಿ ಒಪ್ಪಿಕೊಂಡರು. ನಾವು ಪ್ರತಿಯೊಂದು ಅಗತ್ಯತೆಯಲ್ಲಿ (requirement) ಈ ದಾಖಲೆಯನ್ನು ಉಲ್ಲೇಖಿಸಿದೆವು.
ಪ್ರತಿಯೊಂದು ಡೊಮೇನ್ ಪದವೂ ಅಸ್ಪಷ್ಟವಾಗಿರಬಹುದು ಎಂದು ಭಾವಿಸಿ. ಎರಡೂ ಕಡೆಯವರು ಸಹಿ ಮಾಡುವ ದಾಖಲೆಯಲ್ಲಿ ಅದನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಿ.
ಸಾರಾಂಶ
ಒಬ್ಬ ಬಲಿಷ್ಠ BA ಕೇವಲ ಟಿಕೆಟ್ಗಳನ್ನು ಬರೆಯುವುದಕ್ಕಿಂತ ಹೆಚ್ಚಿನ ಕೆಲಸ ಮಾಡುತ್ತಾರೆ. ಅವರು ನಿಯಂತ್ರಕ ನಿರ್ಬಂಧಗಳು (regulatory constraints) ಮತ್ತು ಕ್ಲಿನಿಕಲ್ ಅರ್ಥದ ವಾಸ್ತುಶಿಲ್ಪಗಳಾಗಿ (architects) ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಾರೆ. ನೀವು ಸಂಕೀರ್ಣ ಸಾಫ್ಟ್ವೇರ್ ಅನ್ನು ನಿರ್ಮಿಸುತ್ತಿದ್ದರೆ, ಈ ಪಾತ್ರವನ್ನು ಕೇವಲ ಹೆಚ್ಚುವರಿ ಕೆಲಸ (overhead) ಎಂದು ಪರಿಗಣಿಸಬೇಡಿ. ಇದು ತಾಂತ್ರಿಕ ಯಶಸ್ಸು ಕ್ಲಿನಿಕಲ್ ವೈಫಲ್ಯವಾಗದಂತೆ ತಡೆಯುತ್ತದೆ.
ಐಚ್ಛಿಕ ಕಲಿಕಾ ಸಮುದಾಯ: https://t.me/GyaanSetuAi