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

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

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

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

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

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

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

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

💡 Забележка: В по-стари материали тези формуляри за твърдения са обозначени като HCFA-1500 и UB-92. И двата бяха заменени: HCFA-1500 стана CMS-1500, а UB-92 беше заменен от UB-04. Използвайте настоящите имена, когато пишете тестови случаи.

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

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

Ключови здравни стандарти, които тестерът трябва да знае

Освен HIPAA, няколко стандарта определят какво трябва да прави едно приложение в здравеопазването и следователно какво трябва да бъде тествано. Разпознаването на всеки един от тях ви показва кой тип тест е той.

Standard	Управлява	Тестването го кара
HIPAA	Поверителност и сигурност на данните на пациентите	Контрол на достъпа, криптиране, одитна следа
HL7 версия 2 / версия 3	Съобщения между клинични системи	Тестване на формата на съобщенията и интерфейса
ФХИР	Съвременен REST API обмен на здравни досиета	API конtracт и тестове за оперативна съвместимост
DICOM	Съхранение и трансфер на медицински изображения	Цялостност на изображението и интеграция на устройството
МКБ-10 / КПТ	Диагноза и кодиране на процедурите	Валидиране на твърдения и тестване на отрицателен път
CMS-1500 / UB-04	Професионални и институционални формуляри за искове	Подаване на искане и валидиране на полета

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

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

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

Разделите по-долу дават примерни сценарии и тестови случаи за всяка подсистема по ред.

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

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

Sr#	Сценарий на теста	Тестови Случаи
1)	Система за достъп до доставчици	Системата на доставчика трябва да ни позволява да въвеждаме, редактираме и запазваме данните на доставчика
2)	Положителен поток Тестване на системата	Той включва сценарии за въвеждане на различни типове доставчици, промяна на подробностите за доставчици, запазване и запитване за тях
3)	Тестване на системата с отрицателен поток	Позволява запазване на информация за доставчика с непълни данни, contracдата на влизане в сила, въвеждане на данни за съществуващи доставчици в системата
4)	Система Тестване на интеграцията	Валидирайте подаването към системата на членовете, финансовата система, системата за искове и портала на доставчика. Също така проверете дали промените от портала на доставчика са въведени в записа на съответния доставчик
5)	Тестване на портал за доставчици на положителен поток	Влезте и вижте подробности за доставчици, статус на заявка и данни за членове Направете заявка за промяна за промяна на име, адрес, телефонен номер и др.
6)	Тестване на портал за доставчици на отрицателен поток	Вижте подробностите за член с невалиден идентификатор Влезте с невалидни идентификационни данни
7)	Тестване на портала на посредник с положителен поток	Влезте и вижте подробности за брокер и плащане на комисионна Направете заявка за промяна на име, адрес, телефон и др.
8)	Тестване на портал за брокер на отрицателен поток	Трябва да включва сценарии за влизане с невалидни идентификационни данни

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Датите са важни и трябва да бъдат точни
• Докато проектирате тестови случаи, вземете предвид различни параметри като различни видове планове, брокери, членове, комисионна и т.н.
• Изисква се пълно познаване на домейна
• Никога не използвайте актуални записи на пациенти като тестови данни. Използвайте анонимизирани или синтетични данни, защото копирането на производствена защитена здравна информация (PHI) в тестова среда само по себе си е нарушение на HIPAA.

Въпроси и Отговори