शिफ्ट संपताना वॉर्ड मॅनेजर तुम्हाला भेटतात. एकाच कॉरिडॉरमधील तीन नातेवाईक व्हिडिओ कॉल करू शकत नाहीत, पेशंटचे टॅबलेट पुन्हा पुन्हा लॉगिन पेजवर रिबाउंड होत आहे आणि कोणीतरी व्हाईटबोर्डवर "WiFi खराब आहे" असे लिहिले आहे. ॲक्सेस पॉइंट्स सुरू आहेत, पोर्टल लाइव्ह आहे आणि डॅशबोर्डवर काहीही त्रुटी असल्याचे दिसत नाही.
कनेक्ट केलेले असणे आणि वापरण्यायोग्य असणे यामधील अंतर हेच आहे जिथे बहुतांश हॉस्पिटल गेस्ट WiFi प्रकल्प अडकतात. सकाळी दहा वाजता बाह्यरुग्ण विभागात किती लोक बसतात याची कोणीही मोजणी करण्यापूर्वीच रेडिओ प्लॅन मंजूर केला गेला. ज्याच्याकडे टेम्पलेट उघडे होते त्यानेच लॉगिन पद्धत निवडली. आणि भेट देणाऱ्यांना सुरक्षिततेबाबत जो सल्ला आवश्यक आहे, मग ते बँक व्यवहार करू शकतात किंवा व्हिडिओ अपॉइंटमेंटमध्ये सामील होऊ शकतात की नाही, तो कधीही जोखीम नोंदवहीवरून (रिस्क रजिस्टर) स्प्लॅश स्क्रीनवर आलाच नाही.
हे तिन्ही निर्णय एकत्र असाव्यात. सिग्नल, ओळख आणि प्रकाशित अपेक्षा हे एकच डिझाइन आहे, नंतर जोडलेल्या डिस्क्लेमरसह नेटवर्क तयार करणे नाही. रेडिओ सर्वेक्षणापासून पायलट वॉर्डपर्यंत, पहिले ॲक्सेस पॉइंट लाइव्ह होण्यापूर्वी क्लिनिकल गव्हर्नन्स ग्रुपकडे मांडण्यायोग्य ट्रेड-ऑफसह, मी ते कसे अनुक्रमित करेन ते येथे आहे.
राष्ट्रीय बेसलाइन आधीच सेट केली आहे. मार्च 2019 च्या अखेरीस NHS WiFi कार्यक्रमाने 98% NHS ट्रस्ट्समध्ये मोफत NHS WiFi सुरू केले होते आणि 8,000 पेक्षा जास्त रुग्ण काळजी केंद्रांपर्यंत पोहोचले होते, ज्यामुळे 63 दशलक्षाहून अधिक भेट देणाऱ्या रुग्णांना मोफत कनेक्टिव्हिटीचा ॲक्सेस मिळाला. व्हिजिटर ॲक्सेस हा आता अतिरिक्त VLAN वर चालणारा दुय्यम प्रकल्प राहिलेला नाही. तो या संपूर्ण पायाभूत सुविधांचा एक भाग आहे.
हार्डवेअर खरेदी करण्यापूर्वी क्षमता आणि रेडिओ लक्ष्यांचे नियोजन करा
व्यस्त वॉर्डमध्ये हॉस्पिटलचे गेस्ट WiFi टिकून राहील की नाही हे तीन आकडे ठरवतात: प्राथमिक सिग्नल, लॅटन्सी आणि चॅनेल लोड. पोर्टल ब्रँडिंग नंतर येते, कारण बे भरल्यावर नेटवर्क कनेक्शन तुटल्यास यापैकी कशाचाही फरक पडत नाही.
NHS England NHS वातावरणात किमान -65 dBm च्या प्रायमरी RSSI ची शिफारस करते आणि स्वीकार्य लेटन्सीचे वर्णन अंदाजे 20 ते 250 ms असे करते, यात असे नमूद केले आहे की कोणताही आकडा अंतिम नाही आणि वापरल्या जाणाऱ्या ॲप्लिकेशन्सविरुद्ध दोन्ही सत्यापित केले जावेत (WiFi परफॉर्मन्स मेट्रिक्सचे मूल्यांकन करण्याबाबत NHS England चे मार्गदर्शक तत्त्वे). याला स्पेसिफिकेशन ऐवजी किमान मर्यादा मानले जावे. बेडसाइडला -65 dBm चे रीडिंग हे सिद्ध करते की लिंक जोडली जाईल. एकाच वॉर्डमध्ये चाळीस लोक संध्याकाळी आठ वाजता व्हिडिओ कॉल करू शकतात की नाही याबद्दल ते काहीही सांगत नाही.
तुमच्याकडे प्रत्यक्ष असलेल्या इमारतीचे सर्वेक्षण करा
परचेस ऑर्डर बाहेर जाण्यापूर्वी सर्वे टूलबद्दल प्रत्येक फ्लोअरवर फिरून माहिती घ्या. सिग्नल कशामुळे खंडित होतो ते नोंदवा: लीड-लाइंड इमेजिंग रूम्स, वॉर्ड राउंडदरम्यान हलणारे बेड पार्टिशन्स, काँक्रीट सर्व्हिस कोअर्स, तळघरातील कॉरिडॉर जिथे नातेवाईक टॅक्सीची वाट पाहतात. बाहेरून येणाऱ्या मार्गांचे देखील सर्वेक्षण करा, कारण डिस्चार्जच्या वेळी लोक तिथेच लिफ्टला कॉल करण्याचा प्रयत्न करत उभे असतात.
बँडची निवड हा क्षमतेचा निर्णय आहे, पसंतीचा नाही. NHS इंग्लंड सार्वजनिक गेस्ट आणि जुन्या उपकरणांसाठी 2.4 GHz ला योग्य बँड मानते, ज्यांना थ्रूपुटपेक्षा जास्त श्रेणीची आवश्यकता असते, आणि क्लायंट्स आणि ॲक्सेस पॉईंट्स सपोर्ट करतील तिथे क्षमतेसाठी 5 GHz मानले जाते. 2.4 GHz लॉक केल्याने जुन्या हँडसेटचे नुकसान होते; सर्वकाही 2.4 GHz वर चालवल्याने तुमचा एअरटाइम सर्वात मोठ्या रेडिओ सिग्नल असलेल्या उपकरणाकडे जातो.
सरासरी ऐवजी पीक टाइमचे नियोजन करा. मंगळवारी सकाळी 10 वाजता मोजलेले नेटवर्क प्रत्येक डिझाइनचे कौतुक करते. परंतु भेट देण्याच्या रात्री सात वाजता घेतलेले रीडिंग महत्त्वाचे असते.
त्यानंतर भेट देणारे नेटवर्कवर काय करतात ते मोजा: प्रति ॲक्सेस पॉईंट समवर्ती क्लायंट्स, चॅनल वापर, पॅकेट लॉस, DHCP आणि DNS प्रतिसाद, आणि प्रमाणीकरण पूर्ण होण्याचा दर. पिंगऐवजी व्हिडिओ आणि मेसेजिंगसह लोड-टेस्ट करा, आणि प्रत्येक वॉर्ड हलवल्यानंतर किंवा इमारतीत बदल केल्यानंतर या सरावाचा पुनरुच्चार करा, कारण उपकरणाचा नवीन तुकडा किंवा पुनर्रचना केलेला बे कव्हरेज मॅप बदलतो.
| मॅट्रिक | लक्ष्य (टार्गेट) | टीपा |
|---|---|---|
| प्राथमिक सिग्नल (RSSI) | -65 dBm किंवा अधिक मजबूत | NHS रुग्णांसाठी असलेल्या क्षेत्रांमध्ये इंग्लंडचे लक्ष्य |
| लेटन्सी | सुमारे 20 ते 250 ms | व्हिडिओ कॉल्स आणि मेसेजिंग विरुद्ध वैधता तपासा |
| पब्लिक आणि जुन्या उपकरणांसाठी (लेगसी डिव्हाइसेस) बँड | 2.4 GHz | अधिक रेंज, कमी क्षमतेसह |
| क्षमतेसाठी बँड | 5 GHz | जिथे क्लायंट्स आणि ॲक्सेस पॉइंट्स सपोर्ट करतात तिथे वापरा |
| पीक वेळेतील एकाच वेळी असलेले क्लायंट्स (कनकरंट क्लायंट्स) | भेट देण्याच्या थेट वेळेत प्रति ॲक्सेस पॉइंट संख्या मोजा आणि नंतर त्यापेक्षा जास्त क्षमतेचे डिझाइन करा | तुमच्या अभ्यागतांची संख्या, विक्रेत्याचा आकडा नाही |
| चॅनेल युटिलायझेशन | भेट देण्याच्या वेळेत सतत जास्त रिडिंग आढळल्यास त्याची तपासणी करा | शांत कालावधीतील रिडिंग्स संघर्ष (कंटेंशन) लपवतात |
| पॅकेट लॉस | लोड टेस्टिंगदरम्यान तुमची स्वतःची मर्यादा निश्चित करा | रात्रीऐवजी पीक वेळेत पुन्हा चाचणी घ्या |
त्या तक्त्यातील प्रत्येक आकृती ही अशी गोष्ट आहे जी तुम्ही पुन्हा मोजता, अशी नाही जी तुम्ही एकदाच अंतिम मानून स्वाक्षरी करता. जर तुम्ही सुरुवातीपासून टेस्ट प्लॅन तयार करत असाल, तर RF सर्व्हे आणि चॅनेल प्लॅनिंगची मार्गदर्शिका मधील सर्व्हे मेकॅनिक्समध्ये अधिक सखोल माहिती समाविष्ट आहे.
प्रत्येक क्षेत्रासाठी योग्य लॉगिन पद्धत निवडा
टीमचे लक्ष विचलित करणारी तडजोड एन्क्रिप्शन किंवा खर्च ही नसते. तर ती म्हणजे असे किती अभ्यागत आहेत जे लॉगिन पूर्णच करत नाहीत.
लॅमिनेटेड साइनवरील सामायिक केलेला पासवर्ड स्वस्त दिसतो, जोपर्यंत तुम्ही नातेवाईकांची रांग एका अंगठ्याने तो क्रॅक झालेल्या स्क्रीनवर टाईप करताना पाहत नाही. यामध्ये प्रति-वापरकर्ता ओळख नसते आणि प्रति-डिव्हाइस एन्क्रिप्शन नसते, त्यामुळे ते रुग्णालयाच्या वॉर्डऐवजी एका दिवसाच्या इव्हेंटसाठी योग्य आहे, जिथे कोणीतरी सहा तास कनेक्ट राहू शकते.
कॅप्टिव्ह पोर्टलद्वारे ईमेल नोंदणी हे बहुतांश ट्रस्टने निवडलेले मॉडेल आहे. Queen Victoria Hospital NHS Foundation Trust ने नोव्हेंबर 2014 मध्ये वॉर्ड, आउटपेशंट प्रतीक्षा क्षेत्रे, त्यांचे कॅफे आणि रेस्टॉरंटमध्ये मोफत WiFi सुरू केले, ज्यामध्ये वापरकर्ते पासवर्डच्या बदल्यात ईमेल पत्त्याची नोंदणी करत असत, आणि प्रत्येकासाठी नेटवर्क क्षमता सुरक्षित ठेवण्यासाठी स्ट्रीमिंग आणि संगीत डाउनलोडवर मर्यादा घातल्या गेल्या होत्या (NHS पेशंट्सना डिजिटल सेवांशी जोडण्याबाबतचा इंग्लंडचा ट्रान्सफॉर्मेशन ब्लॉग). ओळख, अटी आणि बँडविड्थ नियंत्रण एकाच फ्लोमध्ये. तंत्रज्ञान पुढे गेले आहे; पण ही पद्धत बदललेली नाही.

| पद्धत | सेटअप प्रयत्न | एन्क्रिप्शन | अभ्यागत ओळख | सर्वात योग्य |
|---|---|---|---|---|
| अटींच्या पेजसह ओपन नेटवर्क | कमी | काहीही नाही | स्वीकृतीव्यतिरिक्त काहीही नाही | किमान डेटा गरजा असलेले प्रतीक्षा क्षेत्र |
| साइनबोर्डवर सामायिक केलेला पासवर्ड | कमी | फक्त सामायिक केलेली की | प्रति वापरकर्ता काहीही नाही | लहान कार्यक्रम, वॉर्ड नव्हे |
| ईमेलसह कॅप्टिव्ह पोर्टल | मध्यम | WPA2/WPA3 लागू केल्याशिवाय ओपन | सहमतीने मिळवलेला ईमेल | सामान्य अभ्यागत ॲक्सेस |
| Passpoint (Hotspot 2.0) | उच्च | WPA2/3-Enterprise | खाते किंवा प्रोफाईल | पुन्हा येणारे अभ्यागत आणि कर्मचाऱ्यांना जारी केलेली डिव्हाइसेस |
| ब्रँडेड ॲप किंवा खाते | मध्यम | हे ज्या नेटवर्कवर चालते त्याची सुरक्षा पातळी निर्धारित करते | खाते | वारंवार परत येणारे अभ्यागत |
पोर्टल कुठे अपयशी ठरते आणि ते कोण शोधून काढते
काही साधने कॅप्टिव्ह पोर्टल पूर्ण करू शकत नाहीत. जुने Android हँडसेट, लॉक-डाऊन केलेले वर्क लॅपटॉप आणि ई-रीडर्स स्प्लॅश पेजवरच राहतील आणि ते कधीही पूर्ण होणार नाहीत, आणि उघडण्यास नकार देणाऱ्या ब्राउझरचे निवारण पोर्टल ट्यूनिंगद्वारे देखील होऊ शकत नाही. हा तांत्रिक मुद्द्याइतकाच कर्मचाऱ्यांशी संबंधित प्रश्न आहे. वॉर्डमधील कोणालातरी डिव्हाइस नोंदणीकृत करण्याचा मार्ग हवा असतो, आणि एरर मेसेजमध्ये जेनेरिक एरर कोडऐवजी वॉर्ड फोन नंबर असणे आवश्यक आहे.
Passpoint तिथे आपले स्थान मिळवते जिथे तेच लोक परत येतात. एका वेळी प्रोफाइल इन्स्टॉल केल्यानंतर डिव्हाइस एंटरप्राइज-ग्रेड सुरक्षेसह स्वयंचलितपणे कनेक्ट होते, जे वारंवार येणाऱ्या आउटपेशंट्ससाठी आणि कर्मचाऱ्यांना दिलेल्या टॅब्लेटसाठी योग्य आहे. यासाठी ते सपोर्ट करणारे ॲक्सेस पॉइंट्स आणि प्रोव्हिजनिंग पाथ आवश्यक आहे, आणि प्रोफाईल घेऊ न शकणाऱ्या फोनसाठी हा पर्याय नाही.
तुम्ही कोणतीही पद्धत निवडली तरी, मर्यादा अशा ठिकाणी प्रकाशित करा जिथे भेट देणारे त्या वाचू शकतील. नॉटिंगहॅमशायर हेल्थकेअर भेट देणाऱ्यांना सांगते की NHS WiFi सर्व भागात उपलब्ध नसू शकते आणि टीव्ही स्ट्रीमिंग किंवा फोन आणि व्हिडिओ कॉल्ससाठी अनुपयुक्त आहे (नॉटिंगहॅमशायर हेल्थकेअर फ्री WiFi पेज). ही प्रामाणिक माहिती आहे, आणि ती सिनेमाचा अनुभव देण्याचे वचन देणाऱ्या स्प्लॅश पेजपेक्षा अधिक योग्य आहे.
कोणत्याही ईमेल किंवा खाते कॅप्चरसाठी UK GDPR अंतर्गत स्पष्ट संमती पायरी असणे आवश्यक आहे, आणि डेटा केवळ संकलनाच्या वेळी नमूद केलेल्या उद्देशासाठीच ठेवला पाहिजे. कोणत्याही व्यावसायिक नेटवर्कपेक्षा येथे मोठ्या मजकुराची, स्क्रीन-रीडरसाठी सुलभ लॉगिन पेजेस अधिक महत्त्वाची असतात. स्प्लॅश-पेज रचना आणि संमती प्रवाहांची अधिक माहिती या कॅप्टिव्ह पोर्टल डिझाइन मार्गदर्शकामध्ये दिलेली आहे.
गेस्ट ट्रॅफिक क्लिनिकल सिस्टमपासून कसे वेगळे करावे
गेस्ट ॲक्सेसकडे तुमच्या इमारतीमध्ये असलेल्या एका अविश्वासू इंटरनेट सर्व्हिस म्हणून पहा. NHS England चे सेटअप मार्गदर्शक तत्त्वे कंटेंट फिल्टरिंग, स्वीकार्य वापर, ब्रिंग-युअर-ओन-डिव्हाइस नियम आणि क्षमता देखरेख, तसेच स्वीकार्य-वापर पॉलिसी आणि बेकायदेशीर किंवा अयोग्य सामग्री ब्लॉक करण्यावर दस्तऐवजीकरण केलेल्या स्थानिक धोरणांची मागणी करतात. नेटवर्क नियंत्रणे प्रथम येतात, कारण पॉलिसी दस्तऐवज तडजोड केलेल्या फोनला रेडिओलॉजी सबनेट स्कॅन करण्यापासून थांबवत नाही.

- पाहुण्यांना (गेस्ट्स) त्यांच्या स्वतःच्या SSID, VLAN आणि फायरवॉल झोनवर ठेवा. हॅक किंवा तडजोड झालेले अभ्यागताचे डिव्हाइस कोणत्याही महत्त्वाच्या मार्गावर पोहोचणार नाही अशा डेड एंडलाच थांबले पाहिजे. त्या दिवशी कॉन्फिगर करणे सोपे होते म्हणून गेस्ट VLAN मीटिंग रूम किंवा रिसेप्शन सिस्टमसोबत शेअर करणे ही एक सामान्य चूक आहे.
- क्लिनिकल, बायोमेडिकल, मॅनेजमेंट आणि प्रिंटर सबनेटमध्ये लॅटरल ॲक्सेस नाकारा. सोयीसाठी कोणताही अपवाद करू नका. कर्मचाऱ्यांना त्यांच्या वैयक्तिक फोनवरून प्रिंट करता यावे म्हणून प्रिंटर ॲक्सेस दिला जातो, ज्यामुळे मॅनेजमेंट रेंजमध्ये असलेल्या प्रिंट सर्व्हरचा मार्ग मोकळा होतो; ही सुरक्षेतील मुख्य त्रुटी आहे.
- पाहुण्यांना आवश्यक असलेल्या केवळ आऊटबाउंड सेवांनाच अनुमती द्या. याचा सामान्य अर्थ वेब ट्रॅफिक आणि DNS असा होतो, ज्यामध्ये VPN आणि आधुनिक ॲप्लिकेशन आवश्यकता गृहीत धरण्याऐवजी जाणीवपूर्वक हाताळल्या जातात. आऊटबाउंडसाठी सरसकट 'ॲलो-ऑल' नियम तुमच्या गेस्ट VLAN ला दुसऱ्या कोणाच्या तरी अटॅक प्लॅटफॉर्ममध्ये रूपांतरित करतो.
- फिल्टर, रेट-लिमिट, आयसोलेट आणि एक्सपायर करा. DNS आणि कंटेंट फिल्टरिंग, प्रति-क्लायंट रेट लिमिट्स, अभ्यागत एकमेकांना पाहू शकणार नाहीत यासाठी क्लायंट आयसोलेशन आणि इतर ट्रस्टच्या सेटिंग्जवरून घेण्याऐवजी तुमच्या स्वतःच्या गव्हर्नन्स पॉलिसीशी जुळणारी सेशन एक्सपायरी सेट करा. NHS WiFi सेट अप करण्याच्या मार्गदर्शक सूचनांमध्ये ऑथेंटिकेटेड आणि अनऑथेंटिकेटेड अशा दोन्ही पेनिट्रेशन टेस्टद्वारे आयसोलेशन सिद्ध करण्यास सांगितले आहे, त्यामुळे तक्रार आल्यावर बदल करण्यापेक्षा डिझाइनमध्येच हा पुरावा तयार करा.
- ऑथेंटिकेशन, DHCP, NAT आणि सुरक्षा इव्हेंट्स लॉग करा जेव्हा विचारले जाईल तेव्हा सादर करू शकाल अशा लेखी रिटेंशन आणि ॲक्सेस पॉलिसीअंतर्गत हे करा. दस्तऐवजीकरण केलेल्या रिटेंशन नियमाशिवाय लॉगिंग करणे ही पुराव्याच्या नावाखाली एक दायित्व (लायबिलिटी) ठरते.
- लॉगिन पेज सार्वजनिक होण्यापूर्वी झोन नियमांची चाचणी घ्या. गेस्ट कडून क्लिनिकलकडे जाणारा असा कोणताही मार्ग जो प्रतिसाद देतो, तो तातडीने त्याच दिवशी दुरुस्त केला पाहिजे, बॅकलॉग आयटम म्हणून ठेवू नये.
जेव्हा कोणीतरी अभ्यागतांना सत्य सांगते तेव्हा ते अधिक चांगले निर्णय घेतात. काही ट्रस्ट सूचना स्पष्टपणे चेतावणी देतात की गेस्ट ट्रॅफिक संभाव्यतः दुसऱ्या वायरलेस वापरकर्त्याद्वारे इंटरसेप्ट केले जाऊ शकते आणि त्यात गोपनीयतेची कोणतीही अपेक्षा नसते. शेअर केलेला पासवर्ड तुम्हाला जे लिहिणे टाळू देतो, तेच नेमके हे वाक्य आहे आणि अभ्यागतांनी वाचणे आवश्यक असलेले नेमके हेच वाक्य आहे.
शेअर केलेली की ट्रॅफिक एन्क्रिप्ट करते, परंतु कोणताही प्रति-वापरकर्ता ओळख प्रदान करत नाही: पासफ्रेज माहित असणारी प्रत्येक व्यक्ती ही इतर प्रत्येकासारखीच दिसते, ज्यामुळे वरील चेतावणी धोक्याची घंटा वाजवण्याऐवजी प्रामाणिक ठरते. अभ्यागत पॅच केलेल्या उपकरणांसह HTTPS आणि त्यांच्या स्वतःच्या एंडपॉइंट संरक्षणाचा वापर करतील असे डिझाइन गृहित धरत असल्यास, ते त्यांनी स्वीकारलेल्या अटींमध्ये नमूद करा, आणि महत्त्वाचे कार्यक्षम निर्देशक म्हणून पोर्टल पूर्ण करणे, सपोर्ट संपर्क, ब्लॉक-पॉलिसी इव्हेंट्स आणि आयसोलेशन-टेस्ट परिणामांचे मापन करा. अधिक व्यापक आर्किटेक्चरसाठी, हे एंटरप्राइज WiFi सुरक्षा मार्गदर्शक सेगमेंटेशन आणि ॲक्सेस कंट्रोल पॅटर्नमधून मार्ग दाखवते.
गेस्ट WiFi वर भेट देणारे काय सुरक्षितपणे करू शकतात
रुग्ण आणि काळजीवाहू (carers) विचारतात तो प्रश्न हा आहे, आणि हॉस्पिटलच्या बहुतांश पानांवर त्याचे उत्तर नसते: मी या नेटवर्कवर बँकिंग करू शकतो/शकते, व्हिडिओ अपॉइंटमेंटमध्ये सामील होऊ शकतो/शकते किंवा कामाच्या फाइल्स उघडू शकतो/शकते का?
मोफत म्हणजे सुरक्षित असे नाही, आणि ट्रस्टच्या सूचना हे सिद्ध करतात. काही जण NHS WiFi चे वर्णन एक सामायिक सार्वजनिक नेटवर्क म्हणून करतात आणि वैयक्तिक किंवा संवेदनशील माहितीबाबत सावधगिरी बाळगण्याचा सल्ला देतात, तर काही जण ॲक्सेसचे वर्णन नेटवर्क निवडणे आणि अटी स्वीकारण्याव्यतिरिक्त काहीही नाही असे करतात (किंग्स कॉलेज हॉस्पिटल WiFi आणि मनोरंजन पृष्ठ). हे एकाच प्रकारच्या सेवेबद्दलचे दोन वेगवेगळे संदेश आहेत, आणि अभ्यागतांना त्यांच्या ट्रस्टने जे प्रकाशित केले आहे ते मिळते. लॉन्च केल्यानंतर ऐवजी डिझाइनच्या वेळी, SSID आणि लॉगिन पद्धतीसोबत तुमचे संदेश लिहा.
यातील धोका केवळ सुविधेपुरता मर्यादित नाही. विश्वासार्ह WiFi चा अभाव हा असा एक अडथळा आहे ज्यामुळे काही लोक डिजिटल आरोग्य सेवा वापरण्यास कमी सक्षम ठरतात. ब्रrowsing साठी चालणारे परंतु NHS अॅप लॉगिनसाठी न चालणारे गेस्ट नेटवर्क त्यावर सर्वाधिक अवलंबून असलेल्या लोकांना काहीच उपयुक्त ठरत नाही.
| कार्य | गेस्ट WiFi निर्णय | ऐवजी वापर करा |
|---|---|---|
| HTTPS वर सामान्य ब्राऊझिंग, बातम्या आणि नकाशे | योग्य | गेस्ट WiFi |
| HTTPS वर कुटुंबाला मेसेज करणे | योग्य, संवेदनशील तपशील टाळा | गेस्ट WiFi |
| ऑनलाइन बँकिंग | टाळा | मोबाइल डेटा |
| वैयक्तिक आरोग्य डेटासह NHS ॲप लॉगिन | टाळा | मोबाइल डेटा |
| व्हिडिओ सल्लामसलत | टाळा | मोबाइल डेटा |
| कामाच्या प्रणाली आणि फाइल्स | टाळा | कर्मचाऱ्यांद्वारे समर्थित ॲक्सेस |
याचे उत्तर एन्क्रिप्शनमुळे बदलते, आणि नेटवर्कचे नाव अभ्यागतांना त्याबद्दल काहीही सांगत नाही. HTTPS हे पेजवरील मजकुराचे संरक्षण करते, परंतु खुल्या किंवा शेअर-की नेटवर्कवर कनेक्शन डेटा अद्यापही दृश्यमान असतो आणि तो इंटरसेप्ट केला जाण्याची शक्यता असते, त्यामुळेच ट्रस्टच्या सूचनांच्या स्वरामध्ये खूप फरक असतो. प्रति-डिव्हाइस की वर तयार केलेले नेटवर्क हे चित्र बदलते. एक उघडे नेटवर्क मात्र बदलत नाही, मग स्प्लॅश पेज कितीही सुरक्षित वाटत असले तरीही. त्यामुळे "मी येथे सुरक्षितपणे काय करू शकतो/शकते" या प्रामाणिक प्रश्नाचे उत्तर हे पहिला अभ्यागत कनेक्ट होण्यापूर्वीच घेतलेल्या डिझाइन निर्णयावर निश्चित होते. तुमचे आर्किटेक्चर केवळ सुरक्षित HTTPS ब्राऊझिंगला सपोर्ट करत असल्यास, ते उत्तर स्पष्टपणे प्रकाशित करा आणि लगेचच लोकांना इतर पर्यायांकडे निर्देशित करा.
लॉगिन पेजवर छापण्यायोग्य नियम: जर माहिती अनोळखी व्यक्तीच्या स्क्रीनवर दिसल्यास तुमचे नुकसान होणार असेल, तर ती गेस्ट WiFi द्वारे पाठवू नका.
त्याऐवजी लोकांना जाण्यासाठी दुसरी जागा द्या. मोबाइल डेटामध्ये बँकिंग, आरोग्य ॲप लॉगिन आणि व्हिडिओ सल्लामसलत समाविष्ट असते. वैयक्तिक VPN काही कॉर्पोरेट सिस्टमवर मदत करते आणि इतरांना खंडित करते, म्हणून त्याची थेट शिफारस करण्याऐवजी त्याच्या मर्यादा स्पष्ट करा. वॉर्ड कॉम्प्युटरवर मदत करू शकणारा कर्मचारी आणि योग्य डिव्हाइस नसलेल्या कोणासाठीही फोन नंबर, अजिबात स्वतः सेवा न घेऊ शकणाऱ्या अभ्यागतांसाठीची दरी पूर्ण करतो.
गेस्ट WiFi अपयशी ठरल्यास चाचणी करा, मॉनिटर करा आणि प्रतिसाद द्या
लाँच करण्यापूर्वी, दोन सुरुवातीच्या बिंदूंवरून आयसोलेशन टेस्ट्स रन करा: ऑथेंटिकेट झालेले गेस्ट सेशन आणि ऑथेंटिकेट न झालेले सेशन. प्रत्येकाकडून, क्लिनिकल, बायोमेडिकल, मॅनेजमेंट आणि प्रिंटर सबनेटपर्यंत पोहोचण्याचा प्रयत्न करा. कोणतीही यशस्वी पोहोच ही एकाच दिवसात दुरुस्त करण्याची बाब आहे, कारण तुम्ही टेस्ट करत असलेला फेल्युअर मोड हा लिहिला गेला होता परंतु कधीही लागू केला गेला नव्हता असा नियम आहे.
लाँच केल्यानंतर, पाच ऑपरेशनल सिग्नल तुम्हाला डिझाइन कार्य करत आहे की नाही हे सांगतात. सपोर्ट कॉन्टॅक्ट्स सर्वात महत्त्वाचे असतात, आणि ते सहसा मॉनिटरिंग करण्यापूर्वी एखादी त्रुटी समोर आणतात, विशेषतः वॉर्ड शिफ्ट किंवा बिल्डिंग बदलल्यानंतर दोन आठवड्यांत. प्रत्येक मॅट्रिकला एका ट्रिगरशी जोडणी करा जेणेकरून अलर्टमध्ये आलेखाऐवजी सूचना समाविष्ट असेल.
| मेट्रिक | हे का महत्त्वाचे आहे | पुनरावलोकन ट्रिगर |
|---|---|---|
| पोर्टल पूर्ण होण्याचा दर | अभ्यागत खरोखर कनेक्ट होऊ शकतात की नाही हे दाखवते | भेटीच्या वेळेत झालेली सततची घसरण |
| सत्राचा कालावधी | मुदत समाप्ती सेटिंग्ज डिझाइननुसार कार्य करतात याची पुष्टी करते | धोरणाने अनुमती दिलेल्या कालावधीपेक्षा जास्त सत्रे |
| ब्लॉक केलेल्या-पॉलिसीच्या घटना | फिल्टरिंगचा वास्तविक ट्रॅफिकवर परिणाम होत असल्याचे दाखवते | एकाच क्षेत्रात अचानक झालेली वाढ |
| आयसोलेशन-चाचणी अयशस्वी होणे | गेस्ट क्लिनिकल सबनेट्सपर्यंत पोहोचू शकत नाहीत याची पुष्टी करते | कोणतेही अपयश, त्याच दिवशी |
| सपोर्ट संपर्क | लपलेले दोष लवकर उघड करते | वॉर्ड किंवा इमारतीमध्ये बदल झाल्यानंतर झालेली वाढ |
तुम्हाला गरज पडण्यापूर्वीच घटनेचा (incident) क्रम ठरवून ठेवा
अतिथी सत्रे कोण रद्द करू शकते, अतिथी SSID कोण आयसोलेट करू शकते, संक्रमित अभ्यागत डिव्हाइस कसे हाताळले जाते आणि रिटेंशन पॉलिसी अंतर्गत या घटनेची नोंद कोण करते हे लिहून ठेवा. एका पानावर चार नावे असणे संध्याकाळी सात वाजता वाद घालण्यापेक्षा नक्कीच उत्तम आहे. मी इन्फेक्शन-कंट्रोल आणि इस्टेट्स टीम्ससोबत या क्रमाचा एकदा सराव करेन, कारण भेटीच्या वेळेत अतिथी WiFi त्रुटी ही पेशंट-कम्युनिकेशनची देखील समस्या असते, आणि नेटवर्क टीमइतकीच कॉरिडॉरमधील नातेवाईकांनाही मेसेजची गरज असते.
बदल नियंत्रणामध्ये निष्काळजीपणा केल्यामुळे गेस्ट नेटवर्क खराब होते. स्विच बदलणे, नवीन फायरवॉल नियम संच किंवा री-केबल केलेला वॉर्ड यांमुळे लॉन्च करताना बंद केलेला मार्ग पुन्हा उघडू शकतो, आणि आयसोलेशन चाचणी पुन्हा घेईपर्यंत कोणाच्याही ते लक्षात येत नाही. वार्षिक पुनरावलोकनावर अवलंबून राहण्याऐवजी मानक बदल-पश्चात चेकलिस्टमध्ये गेस्ट आयसोलेशनचा समावेश करा.
जेव्हा सपोर्ट कॉल्सची वाढती संख्या ही बॅकग्राउंड नॉइस म्हणून न हाताळता एक घटना (incident) म्हणून हाताळली जाते, तेव्हा मॉनिटरिंगचा खरा फायदा होतो.
तक्रारींचे स्वरूप देखील तपासा. एकाच कॉरिडॉरबद्दल सातत्याने येणाऱ्या तक्रारी ही नेटवर्क कव्हरेजची समस्या असते. संपूर्ण साइटवर लॉगिनबद्दल अचानक वाढलेल्या तक्रारी या सहसा प्रमाणीकरण किंवा DNS शी संबंधित असतात. नवीन उपकरणे आल्यानंतर एकाच बे मधून आलेल्या तक्रारींचा गट या दोन्हीपैकी काहीही नसतो, आणि त्याचे निवारण वायरलेस कंट्रोलरऐवजी इस्टेट्स टीमकडे जाते.
पूर्ण लाँच करण्यापूर्वी पायलट रन करा
एक वॉर्ड, एक भेट देणारा आठवडा आणि पूर्वी घेतलेल्या प्रत्येक निर्णयासाठी लेखी पास किंवा फेल. संपूर्ण इमारतीमध्ये अंमलबजावणी करण्यापूर्वी मी सेट केलेले हे गेट असेल, कारण पायलट चाचणीचा खर्च खराब लाँचच्या तुलनेत खूपच कमी असतो आणि त्यातून स्टिअरिंग ग्रुप कारवाई करू शकेल असा पुरावा मिळतो.
रेडिओपासून सुरुवात करा. प्रत्यक्ष भेटीच्या वेळेत पेशंटच्या खोलीत, प्रतीक्षा क्षेत्रात आणि बाहेर येण्याच्या मार्गावर प्राथमिक सिग्नल मोजा, आणि सर्वेक्षण प्रातिनिधिक होते असे गृहीत धरण्याऐवजी -65 dBm चे उद्दिष्ट कायम राहते याची खात्री करा. त्यानंतर तीन उपकरणांवर सुरुवातीपासून शेवटपर्यंत लॉगिन मार्ग तपासा: एक सध्याचा स्मार्टफोन, एक जुना हँडसेट जो कदाचित पोर्टल कधीही पूर्ण करू शकणार नाही, आणि एक लॅपटॉप. प्रत्येकाला किती वेळ लागतो आणि कोण कुठे प्रक्रिया सोडते याची नोंद ठेवा, कारण ती अर्धवट सोडलेली प्रकरणे म्हणजे तुमची पर्यायी कर्मचारी व्यवस्थापनाची केस आहे.
त्यानंतर ऑथेंटिकेट झालेल्या आणि न झालेल्या सेशन्समधून आयसोलेशन टेस्टिंग येते, ज्यामध्ये शून्य त्रुटी स्वीकारल्या जातात. कोणीही ऑथेंटिकेट करण्यापूर्वी लॉगिन पेजवर सोप्या भाषेतील सुरक्षित-वापराची सूचना दृश्यमान असल्याची खात्री करा, आणि केवळ मसुदा तयार करण्याऐवजी स्वीकार्य-वापर, ब्रिंग-युअर-ओन-डिव्हाइस आणि डेटा-रिटेंशन पॉलिसींवर स्वाक्षरी झाल्याची खात्री करा. तुमच्या मॉनिटरिंग टेबलवरून रिव्ह्यू ट्रिगर्स सेट करा आणि प्रत्येकासमोर नाव निश्चित करा.
जर एकाच मालमत्तेवर कर्मचारी आणि अतिथी ॲक्सेस एकमेकांवर येत असतील, तर हार्डवेअर येण्यापूर्वीच व्हेंडर्सची संक्षिप्त यादी करण्याची हीच योग्य वेळ आहे. Purple एकाच क्लाउड प्लॅटफॉर्मवर अतिथी WiFi, कर्मचारी 802.1X सुरक्षा आणि प्रायव्हेट एरिया नेटवर्क चालवते, ज्यामध्ये कॅप्टिव्ह पोर्टल, Passpoint आणि ॲपचा समावेश असलेल्या अतिथी कनेक्शन पद्धती आणि Entra ID, Google आणि Okta सोबत काम करणारे कर्मचारी ऑथेंटिकेशन समाविष्ट आहे. तुमच्या विद्यमान कंट्रोलर आणि आयडेंटिटी सेटअपशी त्याची तुलना करा, आणि नंतर कोणत्याही मोठ्या गोष्टीसाठी वचनबद्ध होण्यापूर्वी एका वॉर्डवर पायलट बुक करा.
सिग्नल, आयसोलेशन, लॉगिन पूर्ण होणे आणि प्रकाशित अपेक्षांवर यशस्वी होणारी पायलट चाचणी तुम्हाला अशी गोष्ट देते जी व्यवसाय प्रस्तावात क्वचितच असते: निर्णयामागे प्रत्यक्ष अभ्यागतांच्या ट्रॅफिकचा एक आठवडा. चारही घटक यशस्वी झाल्यावरच पुढील वॉर्डमध्ये विस्तार करा.
Purple रुग्णालयांना अतिथी ॲक्सेस अशा प्रकारे चालवण्याचा मार्ग देते जो अभ्यागत सहज पूर्ण करू शकतात, ज्यामध्ये ब्रँडेड कॅप्टिव्ह पोर्टल, Passpoint सपोर्ट आणि प्रति-अभ्यागत संमती त्याच प्लॅटफॉर्ममध्ये समाविष्ट असते जो कर्मचाऱ्यांचे ऑथेंटिकेशन हाताळतो, ज्यामुळे सिग्नल, ओळख आणि प्रकाशित इशारे लाँचनंतर जोडण्याऐवजी आधीच एकत्र प्लॅन केले जातात. जर तुम्ही वॉर्ड पायलटची योजना आखत असाल किंवा उपयुक्तता संपलेला सामायिक पासवर्ड बदलत असाल, तर अतिथी आणि कर्मचारी नेटवर्क तुमच्याकडे आधीपासून असलेल्या ॲक्सेस पॉइंट्सवर कसे बसतात हे पाहण्यासाठी Purple ला भेट द्या.


