Epic ਦੇ ਸੈਪਸਿਸ-ਅਲਰਟ (Sepsis-alert) ਇੰਜਣ ਨੇ Michigan Medicine ਵਿਖੇ 2021 ਦੀ ਇੱਕ ਵੈਲੀਡੇਸ਼ਨ (validation) ਵਿੱਚ ਅਸਫਲਤਾ ਮਾਣੀ, ਜਿਸ ਵਿੱਚ ਦੋ-ਤਿਹਾਈ ਮਰੀਜ਼ਾਂ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰ ਦਿੱਤਾ ਗਿਆ ਜਿਨ੍ਹਾਂ ਨੂੰ ਬਾਅਦ ਵਿੱਚ ਸੈਪਸਿਸ ਹੋ ਗਿਆ ਸੀ, ਜਦੋਂ ਕਿ ਸਾਰੀਆਂ ਦਾਖਲੀਆਂ ਵਿੱਚੋਂ 18% ਲਈ ਅਲਾਰਮ ਵਜਾਇਆ ਗਿਆ ਸੀ। ਇਹ ਗਲਤੀ ਇੱਕ ਕਲਾਸਿਕ ਡਾਟਾ-ਲੀਕੇਜ (data-leakage) ਦੀ ਗਲਤੀ ਹੈ: ਮਾਡਲ ਨੇ ਡਾਕਟਰ ਦੇ ਐਂਟੀਬਾਇਓਟਿਕ ਆਰਡਰ (antibiotic order) ਨੂੰ ਇੱਕ ਭਵਿੱਖਬਾਣੀ ਵਜੋਂ ਗਿਣਿਆ—ਜੋ ਕਿ ਪਹਿਲਾਂ ਹੀ ਸੰਕੇਤ ਹੈ ਕਿ ਇਨਫੈਕਸ਼ਨ ਦਾ ਸ਼ੱਕ ਹੈ—ਅਸਲ ਵਿੱਚ ਇਹ ਉਸ ਫੈਸਲੇ ਨੂੰ ਦੁਹਰਾ ਰਿਹਾ ਸੀ ਜੋ ਕਲੀਨੀਸ਼ੀਅਨ ਪਹਿਲਾਂ ਹੀ ਲੈ ਚੁੱਕਾ ਸੀ।
ਮਾਡਲ ਕਿਉਂ ਅਸਫਲ ਰਿਹਾ
Michigan ਦੀ ਟੀਮ ਨੇ 38,455 ਹਸਪਤਾਲ ਦੇ ਰਹਿਣ ਦੇ ਮਾਮਲਿਆਂ ਦੀ ਜਾਂਚ ਕੀਤੀ, ਜੋ ਕਿ ਇੱਕ ਆਮ ਬਹੁ-ਸਾਲਾ ਕੁਆਲਿਟੀ-ਇੰਪਰੂਵਮੈਂਟ ਪ੍ਰੋਜੈਕਟ ਦੇ ਆਕਾਰ ਦੇ ਬਰਾਬਰ ਹੈ। Epic ਦੇ ਅੰਦਰੂਨੀ ਬੈਂਚਮਾਰਕਸ (benchmarks) ਨੇ ਉੱਚ ਸਟੀਕਤਾ ਦਾ ਵਾਅਦਾ ਕੀਤਾ ਸੀ, ਪਰ ਸੁਤੰਤਰ ਟੈਸਟ ਨੇ ਇਸਦੇ ਉਲਟ ਨਤੀਜੇ ਦਿਖਾਏ। ਮਾਡਲ ਦੇ "ਉੱਚ-ਜੋਖਮ" (high-risk) ਅਲਰਟ ਲਗਭਗ ਪੰਜਵਾਂ ਹਿੱਸਾ ਮਰੀਜ਼ਾਂ ਵਿੱਚ ਚੱਲ ਗਏ, ਫਿਰ ਵੀ ਸੈਪਸਿਸ ਦੇ ਦੋ-ਤਿਹਾਈ ਅਸਲ ਮਾਮਲਿਆਂ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰ ਦਿੱਤਾ ਗਿਆ। ਅਸਲ ਵਿੱਚ, ਸਿਸਟਮ ਨੇ ਬਹੁਤ ਜ਼ਿਆਦਾ ਵਾਰ "ਸਾਵਧਾਨ ਰਹੋ" ਦੀ ਚੀਖ ਮਾਰੀ, ਜਦੋਂ ਕਿ ਉਹਨਾਂ ਘਟਨਾਵਾਂ ਨੂੰ ਫੜਨ ਵਿੱਚ ਅਸਫਲ ਰਿਹਾ ਜਿਨ੍ਹਾਂ ਨੂੰ ਫੜਨਾ ਇਸਦਾ ਮਕਸਦ ਸੀ।
ਇਸਦਾ ਮੂਲ ਕਾਰਨ ਮਸ਼ੀਨ-ਲਰਨਿੰਗ ਐਲਗੋਰਿਦਮ (machine-learning algorithm) ਵਿੱਚ ਕੋਈ ਖਾਮੀ ਨਹੀਂ ਸੀ, ਸਗੋਂ ਇਸ ਵਿੱਚ ਦਿੱਤਾ ਗਿਆ ਡਾਟਾ ਸੀ। ਐਂਟੀਬਾਇਓਟਿਕ ਆਰਡਰ ਦੀ ਮੌਜੂਦਗੀ ਨੂੰ ਇੱਕ ਇਨਪੁਟ ਵਜੋਂ ਵਰਤ ਕੇ, ਮਾਡਲ ਨੇ ਕਲੀਨੀਸ਼ੀਅਨ ਦੇ ਪਹਿਲਾਂ ਹੀ ਲਏ ਗਏ ਫੈਸਲੇ ਦੀ ਭਵਿੱਖਬਾਣੀ ਕਰਨਾ ਸਿੱਖ ਲਿਆ। ਜਦੋਂ ਐਲਗੋਰਿਦਮ ਨੇ ਕਿਸੇ ਮਰੀਜ਼ ਨੂੰ ਫਲੈਗ ਕੀਤਾ, ਤਾਂ ਇਹ ਅਕਸਰ ਇਸ ਲਈ ਸੀ ਕਿਉਂਕਿ ਡਾਕਟਰ ਨੇ ਪਹਿਲਾਂ ਹੀ ਐਂਟੀਬਾਇਓਟਿਕਸ ਦਾ ਆਰਡਰ ਦੇ ਦਿੱਤਾ ਸੀ, ਨਾ ਕਿ ਇਸ ਲਈ ਕਿ ਮਰੀਜ਼ ਦੀ ਸਰੀਰਕ ਵਿਗਿਆਨ (physiology) ਨੇ ਆਉਣ ਵਾਲੇ ਸੈਪਸਿਸ ਦਾ ਸੰਕੇਤ ਦਿੱਤਾ ਸੀ।
ਹਸਪਤਾਲ AI ਵਿੱਚ ਇੱਕ ਵਿਆਪਕ ਸਮੱਸਿਆ
Epic ਦਾ ਸੈਪਸਿਸ ਮਾਡਲ ਸਾਲਾਂ ਤੋਂ ਸੈਂਕੜੇ ਹਸਪਤਾਲਾਂ ਵਿੱਚ ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਹੈ, ਫਿਰ ਵੀ ਲੀਕੇਜ ਦੀ ਗਲਤੀ ਉਦੋਂ ਤੱਕ ਲੁਕੀ ਰਹੀ ਜਦੋਂ ਤੱਕ ਇੱਕ ਕੇਂਦਰਿਤ ਵੈਲੀਡੇਸ਼ਨ ਕੋਸ਼ਿਸ਼ ਨੇ ਇਸਨੂੰ ਸਾਹਮਣੇ ਨਹੀਂ ਲਿਆਂਦਾ। ਇਹ ਘਟਨਾ ਇੱਕ ਪ੍ਰਣਾਲੀਗਤ ਕਮਜ਼ੋਰੀ ਨੂੰ ਦਰਸਾਉਂਦੀ ਹੈ: ਜ਼ਿਆਦਾਤਰ ਹੈਲਥ-ਸਿਸਟਮ AI ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਅਜਿਹੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਜਲਦੀ ਫੜਨ ਲਈ ਲੋੜੀਂਦੀਆਂ ਕਾਰਜਸ਼ੀਲ ਜਾਂਚਾਂ (operational checks) ਦੀ ਘਾਟ ਹੁੰਦੀ ਹੈ।
- ਕੋਈ ਬਾਹਰੀ ਟੈਸਟਿੰਗ ਨਹੀਂ – ਹਸਪਤਾਲਾਂ ਕੋਲ ਕੋਈ ਬਾਹਰੀ ਟੈਸਟਿੰਗ ਨਹੀਂ ਸੀ।
- ਕੋਈ ਨਿਰੰਤਰ ਨਿਗਰਾਨੀ ਨਹੀਂ – ਉਹਨਾਂ ਕੋਲ ਕੋਈ ਨਿਗਰਾਨੀ ਨਹੀਂ ਸੀ।
- ਕੋਈ ਸਪੱਸ਼ਟ ਮਾਲਕੀ ਨਹੀਂ – ਡਾਟਾ ਕੁਆਲਿਟੀ ਅਤੇ ਮਾਡਲ ਪ੍ਰਦਰਸ਼ਨ ਲਈ ਇੱਕ ਨਿਸ਼ਚਿਤ ਟੀਮ ਦੀ ਅਣਹੋਂਦ ਵਿੱਚ, ਮੁੱਦੇ ਅਣਗੌਲਿਆਂ ਰਹਿ ਜਾਂਦੇ ਹਨ।
ਇਹ ਕਮੀਆਂ ਕਈ AI ਪਹਿਲਕਦਮੀਆਂ ਨੂੰ "ਪਾਇਲਟ ਪਰਗਟਰੀ" (pilot purgatory) ਵਿੱਚ ਫਸਾ ਕੇ ਰੱਖਦੀਆਂ ਹਨ, ਜੋ ਕਦੇ ਵੀ ਪ੍ਰੂਫ-ਆਫ-ਕੰਸੈਪਟ ਪੜਾਅ ਤੋਂ ਅੱਗੇ ਨਹੀਂ ਵਧ ਪਾਉਂਦੀਆਂ।
ਖੰਡਿਤ ਡਾਟਾ ਦੀ ਲੁਕੀ ਹੋਈ ਕੀਮਤ
ਸੈਪਸਿਸ ਦਾ ਮਾਮਲਾ ਇਹ ਵੀ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਕਿਵੇਂ ਖੰਡਿਤ ਹੈਲਥ-IT ਈਕੋਸਿਸਟਮ AI ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾਉਂਦੇ ਹਨ। ਆਮ ਰੁਕਾਵਟਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ:
- ਮਰੀਜ਼ਾਂ ਦੇ ਰਿਕਾਰਡ ਪੁਰਾਣੇ EHR ਮੋਡਿਊਲ ਵਿੱਚ ਬੰਦ ਹਨ ਜੋ ਡਾਟਾ ਨੂੰ ਆਪਣੇ ਆਪ ਐਕਸਚੇਂਜ ਨਹੀਂ ਕਰਦੇ।
- ਇਮੇਜਿੰਗ ਅਤੇ ਲੈਬਾਰਟਰੀ ਸਿਸਟਮ ਜੋ ਇੱਕ ਦੂਜੇ ਨਾਲ ਗੱਲ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਜਿਸ ਨਾਲ ਮੈਨੂਅਲ ਫਾਈਲ ਟ੍ਰਾਂਸਫਰ ਕਰਨਾ ਪੈਂਦਾ ਹੈ।
- ਮਰੀਜ਼ਾਂ ਦੇ ਦੁਹਰਾਏ ਗਏ ਪਛਾਣਕਰਤਾ (Duplicate patient identifiers) ਜੋ ਇੱਕੋ ਵਿਅਕਤੀ ਦੇ ਡਾਟਾ ਨੂੰ ਕਈ ਚਾਰਟਾਂ ਵਿੱਚ ਵੰਡ ਦਿੰਦੇ ਹਨ।
- ਕਲੀਨਿਕਲ ਨੋਟਸ ਅਤੇ ਵਾਈਟਲ ਸਾਈਨਜ਼ ਵੱਖਰੇ ਸਿਲੋਜ਼ (silos) ਵਿੱਚ ਸਟੋਰ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਜੋ ਮਾਡਲ ਟ੍ਰੇਨਿੰਗ ਲਈ ਕਦੇ ਵੀ ਮਿਲਾਏ ਨਹੀਂ ਜਾਂਦੇ।
ਜਦੋਂ ਇੱਕ ਮਾਡਲ ਨੂੰ ਸਾਫ਼ ਅਤੇ ਚੋਣਵੇਂ ਡਾਟਾਸੈੱਟ 'ਤੇ ਟ੍ਰੇਨ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਪਰ ਫਿਰ ਇਸਨੂੰ ਲਾਈਵ, ਅਸਪਸ਼ਟ ਡਾਟਾ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਇਸਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਚੁੱਪਚਾਪ ਘਟ ਜਾਂਦੀ ਹੈ। ਕਲੀਨੀਸ਼ੀਅਨ ਜਲਦੀ ਭਰੋਸਾ ਖੋਹ ਲੈਂਦੇ ਹਨ; ਇੱਕ ਨਰਸ ਜਿਸਨੂੰ ਕਈ ਸਕ੍ਰੀਨਾਂ ਰਾਹੀਂ ਅਲਰਟਾਂ ਦਾ ਪਿੱਛਾ ਕਰਨਾ ਪੈਂਦਾ ਹੈ, ਉਹ ਉਹਨਾਂ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰ ਦੇਵੇਗੀ, ਭਾਵੇਂ ਅਸਲ ਐਲਗੋਰਿਦਮ ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ ਸਹੀ ਹੀ ਕਿਉਂ ਨਾ ਹੋਵੇ।
ਭਰੋਸੇਯੋਗ AI ਲਈ ਚਾਰ "ਬੋਰਿੰਗ" ਨੀਂਹਾਂ
ਇੱਕ ਕਾਰਜਸ਼ੀਲ AI ਤੈਨਾਤੀ ਚਾਰ ਵਿਵਹਾਰਕ ਸਮਰੱਥਾਵਾਂ 'ਤੇ ਟਿਕੀ ਹੁੰਦੀ ਹੈ ਜੋ ਸ਼ਾਇਦ ਹੀ ਕਦੇ ਸੁਰਖੀਆਂ ਬਣਦੀਆਂ ਹਨ:
- ਇੰਟਰਓਪਰੇਬਿਲਟੀ (Interoperability) – ਡਾਟਾ ਨੂੰ ਮੈਨੂਅਲ ਐਕਸਪੋਰਟ-ਇੰਪੋਰਟ ਕਦਮਾਂ ਤੋਂ ਬਿਨਾਂ EHRs, ਲੈਬਾਂ, ਇਮੇਜਿੰਗ ਪਲੇਟਫਾਰਮਾਂ ਅਤੇ ਫੈਸਲਾ ਲੈਣ ਵਾਲੇ ਟੂਲਜ਼ ਦੇ ਵਿਚਕਾਰ ਵਹਰ ਚਾਹੀਦਾ ਹੈ।
- ਗਵਰਨੈਂਸ (Governance) – ਇੱਕ ਜਵਾਬਦੇਹ ਵਿਅਕਤੀ ਜਾਂ ਟੀਮ ਕੋਲ ਡਾਟਾ ਕੁਆਲਿਟੀ ਦੀ ਮਾਲਕੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਅਤੇ ਸਮੇਂ ਦੇ ਨਾਲ ਮਾਡਲ ਦੇ ਆਉਟਪੁੱਟ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ।
- ਵਰਕਫਲੋ ਇੰਟੀਗ੍ਰੇਸ਼ਨ (Workflow integration) – ਅਲਰਟ ਕਲੀਨੀਸ਼ੀਅਨ ਦੇ ਮੌਜੂਦਾ ਕੰਮ ਦੇ ਕਿਊ (queue) ਦੇ ਅੰਦਰ ਦਿਖਾਈ ਦੇਣੇ ਚਾਹੀਦੇ ਹਨ; ਵਾਧੂ ਕਲਿੱਕ ਜਾਂ ਸਕ੍ਰੀਨਾਂ ਇਸਦੀ ਵਰਤੋਂ ਨੂੰ ਰੋਕ ਦਿੰਦੀਆਂ ਹਨ।
- ਸਕੈਲੇਬਲ ਆਪਰੇਸ਼ਨਜ਼ (Scalable operations) – ਮਾਡਲ ਦੇ ਉਤਪਾਦਨ (production) ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ ਆਟੋਮੇਟਡ ਨਿਗਰਾਨੀ, ਅਲਰਟ-ਥਕਾਵਟ ਵਿਸ਼ਲੇਸ਼ਣ, ਅਤੇ ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਰੀਟ੍ਰੇਨਿੰਗ ਪਾਈਪਲਾਈਨਾਂ ਜ਼ਰੂਰੀ ਹਨ।
ਇਹਨਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਵੀ ਕਦਮ ਨੂੰ ਛੱਡਣਾ ਇੱਕ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਉਸ ਕਿਸਮ ਦੀ ਚੁੱਪ ਰਹਿਣ ਵਾਲੀ ਅਸਫਲਤਾ ਲਈ ਕਮਜ਼ੋਰ ਬਣਾ ਦਿੰਦਾ ਹੈ ਜੋ Epic ਸੈਪਸਿਸ ਮਾਡਲ ਵਿੱਚ ਦੇਖੀ ਗਈ ਸੀ।
AI ਹੱਲ ਖਰੀਦਣ ਤੋਂ ਪਹਿਲਾਂ ਪੁੱਛੇ ਜਾਣ ਵਾਲੇ ਸਵਾਲ
ਹਸਪਤਾਲ ਠੋਸ ਜਵਾਬਾਂ ਦੀ ਮੰਗ ਕਰਕੇ ਮਹਿੰਗੀਆਂ ਗਲਤੀਆਂ ਤੋਂ ਬਚ ਸਕਦੇ ਹਨ:
- ਕੀ ਤੁਸੀਂ ਮਾਡਲ ਦੁਆਰਾ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਹਰ ਸਿਸਟਮ ਵਿੱਚ ਇੱਕ ਸਿੰਗਲ ਮਰੀਜ਼ ਦੇ ਡਾਟਾ ਦਾ ਪਤਾ ਲਗਾ ਸਕਦੇ ਹੋ?
- ਡਾਟਾ ਕੁਆਲਿਟੀ ਨੂੰ ਬਣਾਈ ਰੱਖਣ ਅਤੇ ਮਾਡਲ ਦੇ ਪ੍ਰਦਰਸ਼ਨ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨ ਲਈ ਨਾਮ ਅਨੁਸਾਰ ਕੌਣ ਜ਼ਿੰਮੇਵਾਰ ਹੈ?
- ਕੀ ਅਲਰਟਾਂ ਦਾ ਟੈਸਟ ਸਿਰਫ਼ ਇੱਕ ਸੈਂਡਬਾਕਸ (sandbox) ਵਾਤਾਵਰਣ ਵਿੱਚ ਹੀ ਨਹੀਂ, ਸਗੋਂ ਅਸਲ ਸ਼ਿਫਟ ਦੌਰਾਨ ਕਲੀਨੀਸ਼ੀਅਨਾਂ ਨਾਲ ਕੀਤਾ ਗਿਆ ਹੈ?
- ਕੀ ਕੋਈ ਦਸਤਾਵੇਜ਼ੀ ਨਿਗਰਾਨੀ ਯੋਜਨਾ ਹੈ ਜੋ ਇਹ ਦੱਸਦੀ ਹੈ ਕਿ ਪਰਫਾਰਮੈਂਸ ਡ੍ਰਿਫਟ (performance drift) ਦੀ ਪਛਾਣ ਕਿਵੇਂ ਕੀਤੀ ਜਾਵੇਗੀ ਅਤੇ ਇਸਨੂੰ ਕਿਵੇਂ ਹੱਲ ਕੀਤਾ ਜਾਵੇਗਾ?
ਜੇਕਰ ਵੈਂਡਰ ਕਿਸੇ ਵਿਅਕਤੀ, ਪ੍ਰਕਿਰਿਆ, ਜਾਂ ਨਿਗਰਾਨੀ ਡੈਸ਼ਬੋਰਡ ਵੱਲ ਇਸ਼ਾਰਾ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਤਾਂ ਸੰਸਥਾ ਨੂੰ ਰੁਕ ਕੇ ਮੁੜ ਮੁਲਾਂਕਣ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।
ਮੁੱਖ ਸਿੱਖਿਆ (The take-away)
Epic sepsis ਮਾਡਲ ਇਸ ਲਈ ਅਸਫਲ ਨਹੀਂ ਹੋਇਆ ਕਿਉਂਕਿ ਮਸ਼ੀਨ ਲਰਨਿੰਗ ਹਸਪਤਾਲਾਂ ਲਈ ਅਣਉਚਿਤ ਹੈ; ਇਹ ਇਸ ਲਈ ਅਸਫਲ ਹੋਇਆ ਕਿਉਂਕਿ ਇਸ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਦੀ ਡਾਟਾ ਪਾਈਪਲਾਈਨ ਅਤੇ ਪ੍ਰਬੰਧਕੀ ਢਾਂਚੇ ਦੀ ਕਮੀ ਸੀ। ਇੱਕ ਮਾਡਲ ਜੋ ਡਾਕਟਰ ਦੇ ਆਪਣੇ ਫੈਸਲੇ ਦੀ ਭਵਿੱਖਬਾਣੀ ਕਰਦਾ ਹੈ, ਇਹ ਚੇਤਾਵਨੀ ਦਿੰਦਾ ਹੈ ਕਿ ਐਲਗੋਰਿਦਮ ਨੂੰ ਨਹੀਂ, ਸਗੋਂ ਡਾਟਾ-ਇੰਜੀਨੀਅਰਿੰਗ ਲੇਅਰ ਨੂੰ ਸੁਧਾਰਨ ਦੀ ਲੋੜ ਹੈ। ਸਿਹਤ ਸੰਭਾਲ ਵਿੱਚ ਭਰੋਸੇਯੋਗ AI ਬਣਾਉਣ ਲਈ ਉਸੇ "ਬੋਰਿੰਗ" ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਜੋ ਕਿਸੇ ਵੀ ਮਹੱਤਵਪੂਰਨ IT ਸਿਸਟਮ ਨੂੰ ਚਲਾਉਣ ਲਈ ਜ਼ਰੂਰੀ ਹੁੰਦਾ ਹੈ: ਸਾਫ਼, ਜੁੜਿਆ ਹੋਇਆ ਡਾਟਾ, ਸਪਸ਼ਟ ਜਵਾਬਦੇਹੀ, ਵਰਕਫਲੋ ਵਿੱਚ ਸ਼ਾਮਲ ਚੇਤਾਵਨੀਆਂ, ਅਤੇ ਸਰਗਰਮ ਨਿਗਰਾਨੀ। ਇਹਨਾਂ ਤੋਂ ਬਿਨਾਂ, ਸਭ ਤੋਂ ਉੱਨਤ ਮਾਡਲ ਵੀ ਅੰਤ ਵਿੱਚ ਗਲਤ ਲੋਕਾਂ ਨੂੰ ਗਲਤ ਚੇਤਾਵਨੀਆਂ ਦੇ ਰਿਹਾ ਹੋਵੇਗਾ।