ಒಬ್ಬ ರೋಗಿಯು “Disconnect My Data” ಎಂಬ ಲೇಬಲ್ ಹೊಂದಿರುವ ಬಟನ್ ಅನ್ನು ಕ್ಲಿಕ್ ಮಾಡುತ್ತಾರೆ. ವೆಬ್ ಆಪ್ ಒಂದು ಹಸಿರು ಚೆಕ್ಮಾರ್ಕ್ ಮತ್ತು ಸಂತೋಷದಾಯಕ ದೃಢೀಕರಣವನ್ನು ತೋರಿಸುತ್ತದೆ. ಹಿನ್ನೆಲೆಯಲ್ಲಿರುವ (background queue) ಯಾವುದೋ ಒಂದು ವರ್ಕರ್ ಪ್ರಕ್ರಿಯೆಯು ತನ್ನ ರಾತ್ರಿಯ ಸಿಂಕ್ಗಾಗಿ ಎಚ್ಚರಗೊಳ್ಳುತ್ತದೆ, ನಿನ್ನೆ ರಚಿಸಲಾದ ಕೆಲಸವನ್ನು (job) ಪಡೆಯುತ್ತದೆ ಮತ್ತು ಎರಡು ವರ್ಷಗಳ ಔಷಧದ ಇತಿಹಾಸವನ್ನು (medication history) ಡೌನ್ಸ್ಟ್ರೀಮ್ ಅನಾಲಿಟಿಕ್ಸ್ ಕ್ಲಸ್ಟರ್ಗೆ ಸ್ಟ್ರೀಮ್ ಮಾಡಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ಬಳಕೆದಾರರು ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ನಂಬಿದ್ದರು. ಆದರೆ ಸಿಸ್ಟಮ್ ಆ ನಂಬಿಕೆಯನ್ನು ದ್ರೋಹ ಎಸಗಿತು.
ಈ ನಿರ್ದಿಷ್ಟ ವೈಫಲ್ಯದ ವಿಧಾನವು (failure mode) ಆರೋಗ್ಯ ದತ್ತಾಂಶದ ವಾಸ್ತುಶಿಲ್ಪದಲ್ಲಿ (health data architecture) ದೊಡ್ಡ ಸಮಸ್ಯೆಯಾಗಿದೆ, ಏಕೆಂದರೆ ಇಲ್ಲಿ ಅಪಾಯದ ಮಟ್ಟ ತುಂಬಾ ಹೆಚ್ಚಿದೆ. ಹಳೆಯದಾದ ಅಥವಾ ಅಸಿಂಧುಗೊಂಡ ಅನುಮತಿಯು (stale permission) ಕೇವಲ ಸಣ್ಣ ಬಗ್ ಅಲ್ಲ; ಅದು ಸಕ್ರಿಯ ಉಲ್ಲಂಘನೆಯಾಗಿದೆ (active breach). ಇದಕ್ಕೆ ಪರಿಹಾರವೆಂದರೆ ಪ್ರತಿಯೊಂದು ದತ್ತಾಂಶ ವಿನಂತಿಯನ್ನು (data request) ಒಂದು 'ಸಮ್ಮತಿ ರಸೀದಿ'ಗೆ (consent receipt) ಜೋಡಿಸುವುದು: ಇದು ಬಳಕೆದಾರರ ಉದ್ದೇಶವನ್ನು UI ಇಂದ ಹಿನ್ನೆಲೆಯಲ್ಲಿರುವ ಪಾಲಿಸಿ ಇಂಜಿನ್, ನಿಮ್ಮ ಡೇಟಾಬೇಸ್ ವಹಿವಾಟುಗಳು ಮತ್ತು ಪ್ರತಿಯೊಂದು ವರ್ಕರ್ ಪ್ರಕ್ರಿಯೆಯವರೆಗೆ ಕೊಂಡೊಯ್ಯುವ ಒಂದು ಸಣ್ಣ, ರಚನಾತ್ಮಕ ದಾಖಲೆಯಾಗಿದೆ. ಇದು ಎಂದಿಗೂ ಕ್ಲಿನಿಕಲ್ ಮೌಲ್ಯಗಳನ್ನು (clinical values) ಸಂಗ್ರಹಿಸುವುದಿಲ್ಲ. ಇದು ಕೇವಲ ಅವುಗಳನ್ನು ಪ್ರವೇಶಿಸುವ ಹಕ್ಕನ್ನು ಮಾತ್ರ ಸಂಗ್ರಹಿಸುತ್ತದೆ, ಮತ್ತು ಇದು ಹಿನ್ನೆಲೆಯಲ್ಲಿ ಗುಟ್ಟಾಗಿ ಬದಲಾಗದಂತಹ ಒಂದು ವರ್ಷದೊಂದಿಗೆ (version) ಮುದ್ರಿತವಾಗಿರುತ್ತದೆ.
ರಸೀದಿಯು ವಾಸ್ತವವಾಗಿ ಏನನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ
ರಸೀದಿಯನ್ನು ಕೇವಲ ಒಂದು ಸೆಷನ್ ಫ್ಲಾಗ್ (session flag) ಎಂದು ಭಾವಿಸಬೇಡಿ, ಬದಲಾಗಿ ಅದನ್ನು ಒಂದು ವ್ಯಾಪ್ತಿಯ ಒಪ್ಪಂದ (scoped contract) ಎಂದು ಭಾವಿಸಿ. ಇದು ಗ್ರಾಂಟ್ ಐಡಂಟಿಫೈಯರ್ (grant identifier), ದತ್ತಾಂಶ ವಿಷಯ (data subject), ಪ್ರವೇಶದ ನಿಖರ ವ್ಯಾಪ್ತಿ (ಲ್ಯಾಬ್ ವರದಿಗಳು, ವೈಟಲ್ಸ್, ಔಷಧದ ಇತಿಹಾಸ), ಸಮಯದ ಮಿತಿ ಹೊಂದಿರುವ ಸಿಂಧುತ್ವದ ಅವಧಿ ಮತ್ತು ವರ್ಷದ ಸಂಖ್ಯೆಯನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. ಫ್ರಂಟ್ಎಂಡ್ ಬಳಕೆದಾರರ ಪರವಾಗಿ ಪ್ರವೇಶವನ್ನು ವಿನಂತಿಸಿದಾಗ, API ಈ ರಸೀದಿಯನ್ನು ನೀಡುತ್ತದೆ. ಫ್ರಂಟ್ಎಂಡ್ ಅದನ್ನು ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ. ಆರೋಗ್ಯ ದತ್ತಾಂಶವನ್ನು ಓದಲು ಬಯಸುವ ಪ್ರತಿಯೊಂದು ಡೌನ್ಸ್ಟ್ರೀಮ್ ಸೇವೆಯು ಒಂದು ಕೇಂದ್ರ ಪಾಲಿಸಿ ಲೇಯರ್ಗೆ (central policy layer) ಈ ರಸೀದಿಯನ್ನು ಸಲ್ಲಿಸಬೇಕು ಮತ್ತು ದಾಖಲೆಯನ್ನು ತೆರೆಯುವ ಮೊದಲು ಸ್ಪಷ್ಟವಾದ ಅನುಮೋದನೆಯನ್ನು ಪಡೆಯಬೇಕು.
ಇದು ಮುಖ್ಯವಾಗಲು ಕಾರಣವೆಂದರೆ, ಆರೋಗ್ಯ ವ್ಯವಸ್ಥೆಗಳು ಹೆಚ್ಚಾಗಿ ಬಳಕೆದಾರರ ಖಾತೆ ಟೋಕನ್ ಅನ್ನು (user account token) ಸಮ್ಮತಿಯೆಂದು ತಪ್ಪಾಗಿ ಭಾವಿಸುತ್ತವೆ. ಟೋಕನ್ ನೀವು ಯಾರು ಎಂದು ಹೇಳುತ್ತದೆ. ರಸೀದಿ ನೀವು ಈಗ ಏನು ಮಾಡಲು ಅನುಮತಿ ಹೊಂದಿದ್ದೀರಿ ಎಂದು ಹೇಳುತ್ತದೆ. ಈ ಎರಡರ ನಡುವೆ ವ್ಯತ್ಯಾಸ ಉಂಟಾದಾಗ, ರಸೀದಿಯೇ ಯಾವಾಗಲೂ ಅಂತಿಮವಾಗಿ ಮಾನ್ಯವಾಗಬೇಕು.
ಎಲ್ಲವನ್ನೂ ವರ್ಷನ್ ಮಾಡಿ (Version Everything)
ನಿಮ್ಮ ಸಮ್ಮತಿ ಸಂಗ್ರಹವನ್ನು (consent store) 'ಅಪೆಂಡ್-ಓನ್ಲಿ ಲಾಗ್' (append-only log) ಆಗಿ ನಿರ್ಮಿಸಿ. ಬಳಕೆದಾರರು ಮೊದಲ ಬಾರಿಗೆ ತಮ್ಮ ಲಸಿಕೆ ದಾಖಲೆಗಳಿಗೆ (immunization records) ಪ್ರವೇಶವನ್ನು ನೀಡಿದಾಗ, ಅದು ವರ್ಷನ್ ಒಂದು ಆಗಿರುತ್ತದೆ. ನಂತರ ಅವರು ನಿರ್ದಿಷ್ಟ ಸೇವಾ ಪೂರೈಕೆದಾರರನ್ನು ಹೊರತುಪಡಿಸುವಂತೆ ವ್ಯಾಪ್ತಿಯನ್ನು ಕಡಿಮೆ ಮಾಡಿದರೆ ಅಥವಾ ಸಂಪೂರ್ಣವಾಗಿ ರದ್ದುಗೊಳಿಸಿದರೆ, ಮೊದಲ ಎಂಟ್ರಿಯನ್ನು ಅಳಿಸಬೇಡಿ. ವರ್ಷನ್ ಎರಡು ಎಂದು ಬರೆಯಿರಿ. ವರ್ಕರ್ ಕೈಯಲ್ಲಿರುವ ರಸೀದಿಯು ಇನ್ನೂ ವರ್ಷನ್ ಒಂದು ಎಂದೇ ಇರುತ್ತದೆ, ಮತ್ತು ಪಾಲಿಸಿ ಇಂಜಿನ್ ವರ್ಷನ್ ಒಂದು ಏನನ್ನು ಅನುಮತಿಸಿತ್ತು ಮತ್ತು ಅದು ನಿರ್ದಿಷ್ಟ ಸಮಯದ ನಂತರ ಬದಲಾಗಿದೆ ಎಂಬುದನ್ನು ನಿಖರವಾಗಿ ನೋಡಬಹುದು.
ಈ ಬದಲಾಗದ ಸ್ಥಿತಿಯೇ (immutability) ನಿಮ್ಮ ಆಡಿಟ್ ಬೆನ್ನೆಲುಬಾಗಿದೆ. ಆರು ತಿಂಗಳ ನಂತರ, ಕಂಪಲೈನ್ಸ್ ಆಫೀಸರ್ ಒಬ್ಬರು ಒಂದು ನಿರ್ದಿಷ್ಟ ETL ಕೆಲಸವು ಗುರುವಾರ ಮಧ್ಯಾಹ್ನ ಏಕೆ ನಡೆಯಿತು ಎಂದು ಕೇಳಿದಾಗ, ಆ ಕೆಲಸವು ಹೊಂದಿದ್ದ ನಿಖರವಾದ ಗ್ರಾಂಟ್ ವರ್ಷನ್ ಅನ್ನು ನೀವು ಪತ್ತೆಹಚ್ಚಬಹುದು ಮತ್ತು ಕೆಲಸ ಪ್ರಾರಂಭವಾದಾಗ ಅದು ಮಾನ್ಯವಾಗಿತ್ತು ಎಂದು ಸಾಬೀತುಪಡಿಸಬಹುದು. ನೀವು ಬಳಕೆದಾರರ ಪ್ರೊಫೈಲ್ನಲ್ಲಿ ಸಮ್ಮತಿಯನ್ನು ಕೇವಲ ಒಂದು ಬೂಲಿಯನ್ ಫ್ಲಾಗ್ (boolean flag) ಆಗಿ ಸಂಗ್ರಹಿಸಿದರೆ, ನೀವು ಆ ಇತಿಹಾಸವನ್ನು ಅಳಿಸಿಹಾಕುತ್ತೀರಿ. "ಇದು ಎಂದಿಗೂ ಅನುಮತಿಸಲಾಗಿರಲಿಲ್ಲ" ಮತ್ತು "ಕೆಲಸ ಪ್ರಾರಂಭವಾದಾಗ ಇದು ಅನುಮತಿಸಲಾಗಿತ್ತು ಆದರೆ ಎರಡು ಗಂಟೆಗಳ ನಂತರ ಬಳಕೆದಾರರು ತಮ್ಮ ನಿರ್ಧಾರವನ್ನು ಬದಲಾಯಿಸಿದರು" ಎಂಬ ಎರಡರ ನಡುವಿನ ವ್ಯತ್ಯಾಸವನ್ನು ಗುರುತಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ನೀವು ಕಳೆದುಕೊಳ್ಳುತ್ತೀರಿ.
ಪ್ರಾಮಾಣಿಕತೆಗಾಗಿ ಎಂಡ್ಪಾಯಿಂಟ್ಗಳನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಿ
ಸಮ್ಮತಿ APIಯು ಸ್ಪಷ್ಟವಾದ ಮತ್ತು ನಿರ್ದಿಷ್ಟವಾದ ರೂಟ್ಗಳನ್ನು (routes) ಹೊಂದಿರಬೇಕು. POST /grants ಹೊಸ ಅನುಮತಿಯನ್ನು ರಚಿಸಲು ಬಿಡಿ. GET /grants/{id} ನಿರ್ದಿಷ್ಟ ರಸೀದಿಯ ಪ್ರಸ್ತುತ ಸ್ಥಿತಿಯನ್ನು ಹಿಂತಿರುಗಿಸಲು ಬಿಡಿ. POST /grants/{id}/revoke ರದ್ದತಿ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಪ್ರಾರಂಭಿಸಲು ಬಿಡಿ. ರದ್ದುಗೊಳಿಸುವ (revoke) ಬಟನ್ ಒತ್ತಿದ ತಕ್ಷಣ ನಿಮ್ಮ ಪೈಪ್ಲೈನ್ಗಳಲ್ಲಿ ಹರಿಯುತ್ತಿರುವ ಆರೋಗ್ಯ ದತ್ತಾಂಶದ ಪ್ರತಿಯನ್ನು ಅಳಿಸಿಹಾಕುತ್ತದೆ ಎಂದು ನಟಿಸಬೇಡಿ. ಬದಲಾಗಿ, 202 Accepted ಸ್ಟೇಟಸ್ನೊಂದಿಗೆ ರದ್ದತಿ ಕಾರ್ಯಾಚರಣೆಯ ಐಡಿ (revocation operation ID) ಅನ್ನು ಹಿಂತಿರುಗಿಸಿ. ಇದು ವಿನಂತಿಯು ನೈಜವಾಗಿದೆ, ಅದು ಪ್ರಾರಂಭವಾಗುತ್ತಿದೆ ಮತ್ತು ಬಳಕೆದಾರರು ಅದನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಬಹುದು ಎಂದು ಬಳಕೆದಾರರಿಗೆ ತಿಳಿಸುತ್ತದೆ.
ಇಂಟರ್ಫೇಸ್ ನಿಧಾನವಾಗಿ ಎನಿಸುವುದರಿಂದ ಬಳಕೆದಾರರು ಡಬಲ್-ಕ್ಲಿಕ್ ಮಾಡಿದಾಗ ಆ ಕಾರ್ಯಾಚರಣೆಯ ಐಡಿ ಬಹಳ ಮುಖ್ಯವಾಗುತ್ತದೆ. ಅವರು ಎರಡನೇ ರದ್ದತಿ ವಿನಂತಿಯನ್ನು ಸಲ್ಲಿಸಿದರೆ, ಮೂಲ ಕಾರ್ಯಾಚರಣೆಯ ಐಡಿಯನ್ನು ಹಿಂತಿರುಗಿಸಿ. ಇಲ್ಲಿ ಐಡೆಂಪೊಟೆನ್ಸಿ (Idempotency) ಎಂಬುದು ಕೇವಲ ಒಂದು ಸೌಲಭ್ಯವಲ್ಲ; ಇದು ಪುನರಾವರ್ತಿತ ಆತಂಕವನ್ನು ತಡೆಯುತ್ತದೆ ಮತ್ತು ಬಳಕೆದಾರರಿಗೆ ಅವರ ವಿನಂತಿಯ ಸ್ಥಿತಿಗತಿಗಾಗಿ ಏಕೈಕ ಸತ್ಯದ ಮೂಲವನ್ನು (single source of truth) ನೀಡುತ್ತದೆ.
ಕೊನೆಯ ಸಾಧ್ಯತೆಯವರೆಗೆ ಅನುಮತಿಯನ್ನು ಕೇಳಿ
API ಗೇಟ್ವೇನಲ್ಲಿ ಸಮ್ಮತಿಯನ್ನು ಪರಿಶೀಲಿಸಿ ನಂತರ ವರ್ಕರ್ನ ಒಳಗಿರುವ ಕ್ಯಾಶ್ಡ್ ಫ್ಲಾಗ್ (cached flag) ಅನ್ನು ನಂಬುವುದು ಒಂದು ಸಾಮಾನ್ಯ ತಪ್ಪು. ಇದನ್ನು ಮಾಡಬೇಡಿ. ವರ್ಕರ್ ತನ್ನ ಕೆಲಸದ ಜೀವನ ಚಕ್ರದ (job lifecycle) ಉದ್ದಕ್ಕೂ ತನ್ನ ರಸೀದಿಯನ್ನು ಹೊಂದಿರಬೇಕು. ಆರೋಗ್ಯ ದಾಖಲೆ ಸಂಗ್ರಹದ ವಿರುದ್ಧದ ಕ್ವೇರಿಯನ್ನು (query) ಕಾರ್ಯಗತಗೊಳಿಸುವ ಮೊದಲು, ಅದು ಪಾಲಿಸಿ ಲೇಯರ್ಗೆ ಕೇಳಬೇಕು: “ಈ ನಿರ್ದಿಷ್ಟ ಗ್ರಾಂಟ್ನ ವರ್ಷನ್ ಮೂರು ಇನ್ನೂ ಈ ನಿಖರ ವ್ಯಾಪ್ತಿಗೆ ಮಾನ್ಯವಾಗಿದೆಯೇ?” ಉತ್ತರ 'ಇಲ್ಲ' ಎಂದಾದರೆ, ವರ್ಕರ್ ನಿಲ್ಲುತ್ತದೆ. ಅದು ಕೆಲಸವನ್ನು ವಿಫಲಗೊಳಿಸುತ್ತದೆ. ಅದು ಮತ್ತೆ ಪ್ರಯತ್ನಿಸುವುದಿಲ್ಲ (retry).
ಇಲ್ಲಿ ರಿಟ್ರೈ ಲಾಜಿಕ್ (retry logic) ವಿಷವಿದ್ದಂತೆ. ವರ್ಷನ್ ವ್ಯತ್ಯಾಸವು ಕೇವಲ ನೆಟ್ವರ್ಕ್ ಸಮಸ್ಯೆಯಲ್ಲ. ಅದು ಮಾನವ ನಿರ್ಧಾರವಾಗಿದೆ. ಬಳಕೆದಾರರು ರದ್ದುಗೊಳಿಸಿದ್ದಾರೆ, ಅಥವಾ ಗ್ರಾಂಟ್ ಅವಧಿ ಮುಗಿದಿದೆ, ಅಥವಾ ವ್ಯಾಪ್ತಿ ಕಡಿಮೆಯಾಗಿದೆ. ನೀವು ಮೂರು ಬಾರಿ ಪ್ರಯತ್ನಿಸಿ ಮತ್ತು ನಾಲ್ಕನೇ ಬಾರಿ ರೇಸ್ ಕಂಡೀಶನ್ (race condition) ಕಾರಣದಿಂದ ಯಶಸ್ವಿಯಾದರೆ, ನೀವು ಸಮ್ಮತಿಯನ್ನು ಉಲ್ಲಂಘಿಸಿದ್ದೀರಿ ಎಂದರ್ಥ. ಈ ವ್ಯತ್ಯಾಸವನ್ನು ಕಠಿಣ ವೈಫಲ್ಯವೆಂದು (hard failure) ಪರಿಗಣಿಸಿ, ಅದನ್ನು ನಿಮ್ಮ dead-letter queue ಅಥವಾ ಆಪರೇಷನ್ಸ್ ಡ್ಯಾಶ್ಬೋರ್ಡ್ಗೆ ಕಳುಹಿಸಿ ಮತ್ತು ಮನುಷ್ಯರು ಅದನ್ನು ತನಿಖೆ ಮಾಡಲು ಬಿಡಿ.
ಗೊಂದಲಮಯ ಸನ್ನಿವೇಶಗಳನ್ನು ನಿರ್ವಹಿಸಿ
ನೈಜ ವ್ಯವಸ್ಥೆಗಳು ಅಚ್ಚುಕಟ್ಟಾದ ಹಂತಗಳಲ್ಲಿ ಚಲಿಸುವುದಿಲ್ಲ. ಬಳಕೆದಾರರು ಹಳೆಯ ಬ್ರೌಸರ್ ಟ್ಯಾಬ್ಗಳನ್ನು ತೆರೆದಿಡುತ್ತಾರೆ. ಬಲ್ಕ್ ಇಂಪೋರ್ಟ್ಗಳು ಇಪ್ಪತ್ತು ನಿಮಿಷಗಳ ಕಾಲ ನಡೆಯುತ್ತವೆ. ಸಿಂಕ್ (sync) ಅರ್ಧಕ್ಕೆ ಮುಗಿಯುತ್ತಿರುವಾಗ ಸ್ಕೋಪ್ಗಳು ಬದಲಾಗಬಹುದು. ಇಂತಹ ಸಂದರ್ಭಗಳಿಗಾಗಿ ನಿಮ್ಮ ಕನ್ಸೆಂಟ್ API ಗೆ ಸ್ಪಷ್ಟ ನಿಯಮಗಳ ಅಗತ್ಯವಿದೆ.
ಹಳೆಯದಾದ ಬ್ರೌಸರ್ ಟ್ಯಾಬ್ಗಳು. ಬಳಕೆದಾರರು ಹೊಸದಾಗಿ ತೆರೆದ ಟ್ಯಾಬ್ನಲ್ಲಿ ಪ್ರವೇಶವನ್ನು ಹಿಂಪಡೆಯುತ್ತಾರೆ. ಹಿಂದಿನ ಪೇಜ್ ಲೋಡ್ನಿಂದ ಗ್ರಾಂಟ್ ಆಬ್ಜೆಕ್ಟ್ ಅನ್ನು ಹೊಂದಿರುವ ಹಳೆಯ ಟ್ಯಾಬ್, ಮರುಸಂಪರ್ಕಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ. ನಿಮ್ಮ ಬ್ಯಾಕೆಂಡ್ ಆ ಹಳೆಯ ರಸೀದಿಯನ್ನು ತಕ್ಷಣವೇ ತಿರಸ್ಕರಿಸಬೇಕು ಮತ್ತು ಹೊಸ ಕನ್ಸೆಂಟ್ ಪರಿಶೀಲನೆಯನ್ನು ಮಾಡಲೇಬೇಕಾದಂತೆ ಒತ್ತಾಯಿಸಬೇಕು. ರದ್ದುಗೊಂಡ ಗ್ರಾಂಟ್ ರದ್ದಾದ ಪಾಸ್ಪೋರ್ಟ್ನಂತೆ ವರ್ತಿಸಬೇಕು: ಹೊಂದಿರುವವರು ಡ್ರಾಯರ್ನಲ್ಲಿ ಹಳೆಯ ಪ್ರತಿಯನ್ನು ಕಂಡುಕೊಂಡಿದ್ದಕ್ಕಾಗಿ ಅದು ಮತ್ತೆ ಚಾಲ್ತಿಯಲ್ಲಿ ಬರಬಾರದು.
ನಡೆಯುತ್ತಿರುವ ಇಂಪೋರ್ಟ್ಗಳು. ಒಂದು ಬಲ್ಕ್ ಇಂಪೋರ್ಟ್ ನಡೆಯುತ್ತಿರುವಾಗ ಬಳಕೆದಾರರು ಪ್ರವೇಶವನ್ನು ಹಿಂಪಡೆದರೆ, ಏಕಕಾಲದಲ್ಲಿ ಎರಡು ವಿಷಯಗಳು ನಡೆಯಬೇಕಾಗುತ್ತದೆ. ಮೊದಲನೆಯದಾಗಿ, ಆ ವರ್ಷನ್ ತಿರಸ್ಕರಿಸಲ್ಪಟ್ಟ ತಕ್ಷಣವೇ ಹೊಸ ಬರವಣಿಗೆಗಳನ್ನು (writes) ಅನುಮತಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿ. ಎರಡನೆಯದಾಗಿ, ಆಪರೇಷನ್ ಐಡಿ ಮೂಲಕ ಬಳಕೆದಾರರಿಗೆ ನೈಜ ಕ್ಲೀನಪ್ ಪ್ರಗತಿಯನ್ನು ತೋರಿಸಿ. ಅವರಿಗೆ ನೈಜ ಸ್ಥಿತಿಯ ಪುಟವನ್ನು ನೀಡಿ: “ರದ್ದತಿ ಸ್ವೀಕರಿಸಲ್ಪಟ್ಟಿದೆ. ಹದಿನೆಂಟು ಬಾಕಿ ಇರುವ ಬರವಣಿಗೆಗಳನ್ನು ಅಳಿಸಲಾಗುತ್ತಿದೆ.” ಈಗಾಗಲೇ ಅಮಾನ್ಯ ಎಂದು ಗುರುತಿಸಲಾದ ಗ್ರಾಂಟ್ ವರ್ಷನ್ ಬಳಸಿ ವರ್ಕರ್ಸ್ ಡೇಟಾವನ್ನು ಕಮಿಟ್ ಮಾಡದಂತೆ ನೋಡಿಕೊಳ್ಳಿ.
ಸ್ಕೋಪ್ ಬದಲಾವಣೆಗಳು. ಬಳಕೆದಾರರು ಮೂಲತಃ ಐದು ವರ್ಷಗಳ ಇತಿಹಾಸಕ್ಕೆ ಪ್ರವೇಶವನ್ನು ನೀಡಿದ್ದಾರೆ ಮತ್ತು ನಂತರ ಅದನ್ನು ಆರು ತಿಂಗಳಿಗೆ ಸರಿಪಡಿಸಿದ್ದಾರೆ ಎಂದು ಭಾವಿಸೋಣ. ಮೂಲ ಗ್ರಾಂಟ್ ಅನ್ನು ಬದಲಾಯಿಸಬೇಡಿ. ವರ್ಷನ್ ಒಂದನ್ನು ಮುಚ್ಚಿ, ಕಿರಿದಾದ ಅವಧಿಯೊಂದಿಗೆ ವರ್ಷನ್ ಎರಡನ್ನು ವಿತರಿಸಿ, ಮತ್ತು ನಡೆಯುತ್ತಿರುವ ಯಾವುದೇ ಪ್ರಕ್ರಿಯೆಗಳು ಹೊಸ ಮಿತಿಗೆ ಅನುಗುಣವಾಗಿ ಹೊಂದಾಣಿಕೆ ಮಾಡಿಕೊಳ್ಳುವಂತೆ ಒತ್ತಾಯಿಸಿ. ಹಳೆಯ ವರ್ಷನ್ ನಿಮ್ಮ ಲಾಗ್ನಲ್ಲಿ ಒಂದು ಐತಿಹಾಸಿಕ ಸತ್ಯವಾಗಿ ಉಳಿಯಬೇಕೇ ಹೊರತು, ಚಾಲ್ತಿಯಲ್ಲಿರುವ ಅನುಮತಿಯಾಗಿ ಅಲ್ಲ.
ಕಠಿಣ ಭದ್ರತಾ ನಿಯಮಗಳು
ರಸೀದಿಗಳೇ ಸೂಕ್ಷ್ಮವಾಗಿರುತ್ತವೆ, ಆದರೆ ಅವು ಕ್ಲಿನಿಕಲ್ ಡೇಟಾ ಅಲ್ಲ. ನಿಮ್ಮ ಆರ್ಕಿಟೆಕ್ಚರ್ನಲ್ಲಿ ಅವುಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿಡಿ. ಕೇವಲ ರೋಗಿ ಅಥವಾ ನಿರ್ದಿಷ್ಟವಾಗಿ ನಿಯೋಜಿಸಲಾದ ಪಾತ್ರಗಳು—ಉದಾಹರಣೆಗೆ ಕಾನೂನುಬದ್ಧ ಪಾಲಕ ಅಥವಾ ಅಧಿಕೃತ ಆರೈಕೆದಾರ—ರಸೀದಿಯನ್ನು ನೋಡಲು ಅಥವಾ ರದ್ದುಗೊಳಿಸಲು ಸಾಧ್ಯವಾಗಬೇಕು. ಇದನ್ನು ಕೇವಲ UI ರೂಟಿಂಗ್ ಟೇಬಲ್ನಲ್ಲಿ ಮಾತ್ರವಲ್ಲದೆ, ಡೇಟಾ ಲೇಯರ್ನಲ್ಲಿ ಜಾರಿಗೊಳಿಸಿ.
ಕೆಲಸಗಳು ವಿಫಲವಾದಾಗ ನಿಮ್ಮ ಎರರ್ ಲಾಗ್ಸ್ ಆರೋಗ್ಯ ಡೇಟಾವನ್ನು ಒಳಗೊಳ್ಳಲು ಪ್ರಯತ್ನಿಸುತ್ತವೆ. ಈ ಪ್ರವೃತ್ತಿಯನ್ನು ತೀವ್ರವಾಗಿ ಎದುರಿಸಿ. ಅಮಾನ್ಯ ಕನ್ಸೆಂಟ್ ರಸೀದಿಯನ್ನು ಪ್ರಸ್ತುತಪಡಿಸಿದ ಕಾರಣದಿಂದಾಗಿ ವರ್ಕರ್ ವಿಫಲವಾದಾಗ, ಗ್ರಾಂಟ್ ಐಡಿ, ವರ್ಷನ್ ಮತ್ತು ಎರರ್ ಅನ್ನು ಲಾಗ್ ಮಾಡಿ. ವರ್ಕರ್ ಪಡೆಯಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದ್ದ ರೋಗಿಯ ಗುರುತಿನ ಸಂಖ್ಯೆ, ರೋಗನಿರ್ಣಯ ಕೋಡ್ ಅಥವಾ ಲ್ಯಾಬ್ ಮೌಲ್ಯವನ್ನು ಎಂದಿಗೂ ಲಾಗ್ ಮಾಡಬೇಡಿ. ಲಾಗ್ನಲ್ಲಿರುವ ಆರೋಗ್ಯ ಡೇಟಾ ಬೂಸ್ಟಿನಂತೆ ಹರಡುತ್ತದೆ: ಅದು ಬ್ಯಾಕಪ್ ಆಗುತ್ತದೆ, ಇಂಡೆಕ್ಸ್ ಆಗುತ್ತದೆ ಮತ್ತು ನಿಮ್ಮ ಸಾಮಾನ್ಯ ಪ್ರವೇಶ ನಿಯಂತ್ರಣಗಳನ್ನು ಬೈಪಾಸ್ ಮಾಡುವ ರೀತಿಯಲ್ಲಿ ಮರೆಯಾಗುತ್ತದೆ.
ಕೊನೆಯದಾಗಿ, ಸಿಸ್ಟಮ್ ರಿಕವರಿ ಸಮಯದಲ್ಲಿ ಎಂದಿಗೂ ಹಳೆಯ ಸಕ್ರಿಯ ಗ್ರಾಂಟ್ ಅನ್ನು ಮರುಸ್ಥಾಪಿಸಬೇಡಿ. ನೀವು ಡೇಟಾಬೇಸ್ ಅನ್ನು ರೋಲ್ ಬ್ಯಾಕ್ ಮಾಡಿದರೆ ಅಥವಾ ರದ್ದತಿಗಿಂತ ಹಿಂದಿನ ಗ್ರಾಂಟ್ ಟೇಬಲ್ನ ವರ್ಷನ್ ಅನ್ನು ಹೊಂದಿರುವ ಸ್ನ್ಯಾಪ್ಶಾಟ್ ಅನ್ನು ಮರುಸ್ಥಾಪಿಸಿದರೆ, ಸೇವೆ ಹೊಸ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಸ್ವೀಕರಿಸುವ ಮೊದಲು ನಿಮ್ಮ ರನ್ಬುಕ್ ಆ ಪುನರುಜ್ಜೀವನಗೊಂಡ ಅನುಮತಿಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಅಮಾನ್ಯಗೊಳಿಸಬೇಕು. ಐತಿಹಾಸಿಕ ಕನ್ಸೆಂಟ್ ಸ್ಥಿತಿಗಳು ಆಡಿಟ್ ಲಾಗ್ನಲ್ಲಿ ಇರಬೇಕೇ ಹೊರತು, ಸಕ್ರಿಯ ನಿಯಮಗಳ ಸೆಟ್ನಲ್ಲಿ ಎಂದಿಗೂ ಇರಬಾರದು.