Тестване на домейн в HealthCare с примерни тестови случаи

Преди да започнем тестването, нека бързо изучим основните знания в областта на здравеопазването.

Тестване на домейн в HealthCare

Тестване на домейни в здравеопазването е процес за тестване на приложението за здравеопазване за различни фактори като стандарти, безопасност, съответствие, кръстосана зависимост с други субекти и др. Целта на тестването на домейни в здравеопазването е да осигури качество, надеждност, производителност, безопасност и ефективност на приложението за здравеопазване .

Основни познания в областта на здравеопазването

Цялата здравна система е сплетена един с друг от един орган, който е болница или доставчик (лекар).

Докато другите субекти включват-

• Застрахователна компания: Medicare, Medicaid, BCBS и др.
• Пациент / Потребители: Записан пациент
• Регулаторен орган: HIPAA, оценка на OASIS, HCFA 1500 и UB92 и др.
• Доставчици на решения за здравеопазване и наука за живота

Основна терминология на здравната система

• Доставчик : медицински специалист (лекар), медицинска група, клиника, лаборатория, болница и др., Лицензирани от здравните служби
• Иск: Искане до вашата здравноосигурителна компания да плати сметка за здравни услуги
• Брокер: Застрахователен специалист, който преговаря, осигурява застраховка от името на застрахован или бъдещ застрахован
• Финанси: Застрахователните органи, които плащат за медицински разходи, могат да бъдат държавни (Medicare или Medicaid) или търговски (BCBS)
• Medicare: Федерална здравноосигурителна програма за възрастни хора и хора с трайни увреждания
• Medicaid: Съвместна и държавна програма, която помага на семействата и лицата с ниски доходи да плащат разходите, свързани с медицинските грижи
• CPT код : Настоящият процедурен терминологичен код е медицински код, определен за описание на медицински, хирургични и диагностични услуги
• HIPAA : Това е набор от правила и разпоредби, които лекарите, болниците, доставчиците на здравни услуги и здравният план трябва да следват, за да предоставят своите услуги

В този урок ще научим-

• Основни познания в областта на здравеопазването
• Бизнес процес в здравеопазването
• Тестване на системата на доставчици
• Тестване на брокерска система
• Тестване на членска система
• Тестване на система за рекламации
• Тестване на финансова система
• Тестване при спазване на нормативните изисквания
• Тестване на ефективността на приложението в здравеопазването
• Други видове тестване за приложение в здравеопазването
• Тестови предизвикателства в приложението на здравеопазването
• Тестване на здравни устройства
• Полезни съвети за здравни тестове

Бизнес процес в здравеопазването

Повечето здравни организации са адаптирали софтуерна програма за обработка на гладкото функциониране на системата. Тази софтуерна система предоставя цялата информация в един документ за всеки обект, който се занимава с това.

Връзката на цялата тази система с едно уеб приложение е огромна задача, а нейната ефективна работа е дори по-голяма задача. Строгите тестове на това здравно приложение са задължителни и трябва да преминат през различни фази на тестване.

В този урок ще научим,

Тестване на системата на доставчици

Примерни тестови сценарии и тестови случаи за система (лекар / болница) :

Тест сценарий	Тестови случаи
Достъп до системата на доставчиците	Системата на доставчика трябва да ни позволи да въвеждаме, редактираме и запазваме данните на доставчика
Тестване на системата с положителен поток	Включва сценарии за въвеждане на различни видове доставчици, промяна на данните за доставчиците, запазване и запитване към тях
Тестване на системата с отрицателен поток	Позволява да се запазва информация за доставчика с непълни данни, дата на влизане в сила на договора, въвеждане на подробности за съществуващите доставчици в системата
Тестване на системната интеграция	Проверете емисията на системата за членове, финансовата система, системата за искове и портала на доставчика. Също така проверете дали промените от портала на доставчика са въведени в записа на съответния доставчик
Тестване на портала на доставчици на положителен поток	Влезте и прегледайте подробностите за доставчиците, състоянието на искането и данните за членовете Направете заявка за промяна, за да промените името, адреса, телефонния номер и т.н.
Тестване на портала на доставчици на отрицателен поток	Прегледайте данните за члена с невалиден идентификатор Влезте с невалидни идентификационни данни
Тестване на портала с положителен поток	Влезте и вижте подробности за брокера и комисионното плащане Направете заявка за промяна на името, адреса, телефонния номер и т.н.
Тестване на портала с отрицателен поток	Той трябва да включва сценарии за влизане с невалидни идентификационни данни

Тестване на брокерска система

Примерни тестови сценарии и тестови случаи за брокерска система :

Sr #	Тест сценарий	Тестови случаи
1)	Брокерска система	Той трябва да може да редактира, въвежда и съхранява данни на посредник Изчисляване на комисионната на брокера въз основа на данните за плащане на премията от системата-член
2)	Тестване на системата за положителен поток	Въведете, запишете и редактирайте записа на брокери за различни видове брокери За активните брокери изчисляват комисионната, като създават файл за емисия със съответния запис за членове с различен план
3)	Тестване на системата с отрицателен поток	Въведете запис на брокер с непълни данни и запазете за различни видове брокер Чрез създаване на файл с емисии със съответния запис за членове с различен план изчислете комисионната за прекратения брокер Чрез създаване на файл за емисия със съответния запис за членове с различен план изчислете комисионната за невалидния брокер
4)	Тестване на системата	За система надолу по веригата, като финансова система, портал за брокери и система за членове валидира емисиите Проверете дали промените от брокерския портал са включени в съответния запис на брокер

Тестване на членска система

Примерни тестови сценарии и тестови случаи за членска (пациентска) система :

Sr #	Тест сценарий	Тестови случаи
1)	Членска система	Регистрирайте, възстановете и прекратете член Премахнете и добавете зависим Генериране на сметка за премия Обработвайте плащания на премии
2)	Тестване на системата за положителен поток	С текущата, миналата и бъдещата дата на влизане в сила се регистрират различни видове членове Запитване и смяна на членовете Направете премиум сметка за активен член за следващия месец Прекратяване на активен член с минали, настоящи и бъдещи дати на прекратяване, по-големи от датата на влизане в сила Презапишете прекратен член с текуща, минала и бъдеща дата на влизане в сила Възстановете прекратен номер
3)	Тестване на системата с отрицателен поток	При недостатъчно данни регистрирайте член За прекратен член представете сметка за премия за следващия месец
4)	Тестване на системната интеграция	Проверете емисията към системи надолу по веригата, като портал за доставчици, портал за брокери, финансова система и система за вземания Проверете дали промените от портала за членове са включени в съответния запис на член Обработвайте плащането на премийна сметка, генерирана с емисията от портала на членовете, която съдържа подробности за извършеното плащане

Тестване на система за рекламации

Примерни тестови сценарии и тестови случаи за система за искове :

#	Тестови сценарии	Тестови случаи
1)	Система за искове	Исковете в здравеопазването трябва да редактират, въвеждат и обработват искове за член, както и за зависими При невалидни искове той трябва да изхвърля грешки при въвеждане на неправилни данни
2)	Тестване на системата за положителен поток	Той трябва да включва сценария за редактиране, въвеждане и обработка на искове за член, както и зависим
3)	Тестване на системата с отрицателен поток	Той трябва да валидира и въведе иск с невалиден процедурен код и диагностичен код Потвърдете и въведете иск с неактивен идентификатор на доставчика Потвърдете и въведете иск с прекратен член
4)	Системна интеграция	Той трябва да включва сценарий за валидиране на емисията към системи надолу по веригата, като доставчик и финансов портал

Тестване на финансова система

Примерни тестови сценарии и тестови случаи за финансова система

Sr #	Тестови сценарии	Тестови случаи
1)	Финансова система	Регистрирайте, възстановете и прекратете член
2)	Тестване на системата с положителен поток	Той трябва да провери дали е избран правилен номер на акаунт или адрес за съответния член, доставчик или брокер за плащането
3)	Тестване на системата с отрицателен поток	Проверете дали плащането се извършва за невалиден идентификатор на член, доставчик или брокер, като създадете съответния запис в емисията Проверете дали плащането се извършва за невалидна сума за члена, доставчика или брокера, като създадете съответни записи в емисията

Тестване за спазване на нормативните изисквания

Защитата на чувствителните данни на пациентите и здравната информация е от първостепенно значение за здравните регулаторни органи. Тестването трябва да се извършва в съответствие с такива регулаторни органи.

Примерни тестови сценарии и тестови случаи за спазване на нормативните изисквания :

Sr #	Тестови сценарии	Тестови случаи
1)	Удостоверяване на потребителя	Използване на метод за проверка, за да се гарантира, че правилните потребители получават вход и отказват на други
2)	Разкриване на информация	Разрешаването на достъп до информация се основава на ролята на потребителя и ограниченията на пациента
3)	Трансфер на данни	При всяко прехвърляне точките гарантират, че данните са криптирани
4)	Одитна пътека	Всички транзакции и всички опити за достъп до данни с подходящ набор от информация за одиторски следи се записват
5)	Изпитване на разумността, свързано с регулаторния орган	Извършете тестове за здравословно състояние и проверете дали криптирането на данните се извършва в определени области като EPHI (електронна защитена здравна информация)

Тестване на ефективността на приложението в здравеопазването

Преди изготвянето на тестови сценарии трябва да се имат предвид някои изисквания на системата. Например доставчиците на здравни грижи (лекари / болници) осигуряват грижи 24/7, така че софтуерът за чекиране на пациентите трябва да е на разположение по всяко време. Също така, той трябва да комуникира със застрахователните компании, за да провери информацията за полиците, да изпрати искове и да получи парични преводи. Тук архитектурата трябва да дефинира различните компоненти на системата, протокола за комуникация със застрахователните компании и как да се внедри системата, така че да отговаря 24/7.

Като тестер трябва да се уверите, че здравната софтуерна система отговаря на желания показател за натоварване / производителност.

Други видове тестване за приложение в здравеопазването

• Функционално тестване : Тестване на приложението в здравеопазването спрямо функционалните възможности
• Тестване за съответствие : Тест за съответствие Реквизити за сигурност на здравеопазването и индустриални рамки
• Тестване на платформа : Тестване на приложения на мобилната платформа и тестване на приложения за съвместимост между браузърите
• Тестване на оперативна съвместимост : Тестване на съответствие със стандартите за оперативна съвместимост (Например; DICOM, HL7, CCD / CDA)

Тестови предизвикателства в приложението на здравеопазването

Предизвикателствата при тестване при тестване на приложения за здравеопазване не се различават от другите тестове за уеб приложения.

• Изисква опит в тестването и обикновено е с висока цена
• Изисква оперативна съвместимост, съответствие, регулаторни изисквания, тестове за безопасност, безопасност освен редовни техники за тестване (нефункционално, функционално и интеграционно тестване)
• Тестването трябва да се извършва, като се имат предвид стандартите за безопасност и нормативни изисквания, тъй като всяка грешка може да причини пряк ефект върху живота на пациента
• Екипът за тестване трябва да е добре запознат с различните функционалности, клиничната употреба и средата, за която ще се използва софтуерът
• Продуктът за здравеопазване трябва да отговаря на различни стандарти като FDA, ISO и CMMI, преди да може да се използва
• Кръстосаната зависимост на софтуерните тестери трябва да гарантира, че всякакви промени в единия компонент или слой не трябва да водят до страничен ефект върху другия.

Тестване на здравни устройства

Въпреки че софтуерът за здравни устройства не е пряка грижа на пациента, те също изискват стриктно тестване като друго софтуерно тестване. Например, рентгеновите апарати, които се контролират от софтуерни програми, трябва да бъдат тествани добре, защото всяка грешка при тестване в софтуера може да доведе до сериозен ефект върху пациента.

FDA (Администрация по храните и лекарствата) има насоки за мобилни и уеб приложения за медицински устройства. Докато тествате медицински изделия, правилният функционален план за изпитване заедно с критериите за преминаване и отказ също е част от насоките на FDA. Когато се изпълни план за изпитване, резултатите се събират и докладват на FDA. Този процес гарантира, че устройството отговаря на стандарта на регулаторните органи.

Полезни съвети за здравни тестове

Докато тествате софтуера, можете да разгледате някои важни съвети за тестване на здравната система.

• Датите са важни и трябва да бъдат точни
• При проектирането на тестови случаи се вземат предвид различни параметри като различни видове план, брокери, членове, комисионни и т.н.
• Изискват се пълни познания за домейна