Генерація звітів з інтегрованим контролем якості

Реферат: Звіти генеруються обчислювальною машиною з використанням користувацького введення в шаблон і величин контролю якості, що автоматично додаються. Звіти контролю якості можуть автоматично генеруватися за вибрані проміжки часу, такі як день, місяць або рік. Таким чином, користувачі зможуть додержуватися необхідних стандартів гарантій якості. UA 97803 C2 (12) UA 97803 C2 UA 97803 C2 5 10 15 20 25 30 35 40 45 50 55 60 Даний винахід належить до способів і систем генерації звітів, які інтегрують значення з баз даних і включають інформацію контролю якості, і, більш конкретно, до систем і способів генерації звітів про лабораторні дослідження з контролем якості, який відповідає необхідним стандартам. Ручне формування звітів може бути трудомістким і тривалим процесом. Такі винаходи як стенографія і розпізнавання мови комп'ютером скоротили кількість часу, необхідного для створення звітів. Програмне забезпечення для розпізнавання мови, таке як Naturally Speaking від компанії Dragon і Via Voice від IBM включає поліпшені версії з обмеженою можливістю контролю набору команд, таких як макрокоманди і голосові команди Via Voice. Програмне забезпечення може не тільки розпізнавати дані звіту, але також воно надає користувачеві обмежені можливості диктування команд програмному забезпеченню так, що програмне забезпечення може надавати форматування або переміщатися по тексту без будь-якого втручання користувача. У сучасному світі стандарти, інструкції і часто закони вимагають визначеного набору гарантій якості або контролю якості різних звітів, що впливають на життя людей. Типовою вимогою з контролю якості є взяття пробної вибірки об'ємом в п'ять або десять процентів рід загальної кількості згенерованих звітів і правильності їх генерації. Будь-яка схема пробної вибірки вимагає, щоб вибірка проводилася акуратно, таким чином, щоб вона була репрезентативною відносно початкової множини, в нашому випадку - відносно первинної множини згенерованих звітів. Починаючи з 90-х років, судово-медичні експерти почали використовувати програми розпізнавання мови для генерації звітів. Основна проблема програмного забезпечення по розпізнаванню мови і загалом запису мови під диктування, заміненого програмним забезпеченням, є те, що генерація корисних звітів з гарантією якості є складною і трудомісткою. Було б вигідно мати систему і спосіб генерації звітів, які забезпечують більш кращий контроль якості, ніж наявний на даний момент. Згідно з одним з аспектів даного винаходу надана система, яка включає в себе конфігурований пристрій витягання даних і пристрій введення, сконфігурований для прийому даних і однієї або більше команд. Також система включає в себе обчислювальну машину, сполучену з пристроєм введення щонайменше протягом деякого часу. Обчислювальна машина одержує дані від пристрою введення в одній або більше командах, обчислювальна машина сконфігурована для доступу до настроюваного пристрою витягання даних. Обчислювальна машина додатково сконфігурована генерувати звіт, який включає в себе дані, величини, одержані від конфігурованого пристрою витягання даних, у відповідь щонайменше на одну або більше команд, і значення контролю якості, визначені обчислювальною машиною. Обчислювальна машина додатково сконфігурована зберігати дані в одному або більше вибраних розташувань в конфігурованому пристрої витягання даних у відповідь на вибрані одну або більше команд. Відповідно до іншого аспекту даного винаходу наданий спосіб створення звіту. Спосіб включає в себе використання пристрою введення для введення приміток про одне або більше спостережень. Примітки включають в себе одну або більше команд про те, як представляти в звіті одне або більше спостережень. Також спосіб включає в себе пристрій, який приймає примітки від пристрою введення, і пристрій, який виділяє одну або більше команд із приміток і поміщає одне або більше спостережень в звіт, на основі однієї або більше команд. Спосіб додатково включає в себе пристрій, який додає в звіт одне або більше значень якості і генерує звіт. Ще в одному аспекті даного винаходу надана база даних, яка включає в себе перший набір записів, при цьому кожне входження першого набору записів відповідає входженню даних категорії в першому наборі записів. Також база даних включає в себе другий набір записів, при цьому кожне входження другого набору записів відповідає команді категорії у другому наборі. Кожна команда категорії у другому наборі включає в себе відповідний код. Також база даних включає в себе машину бази даних, сконфігуровану для витягання рядка значень, при цьому кожний рядок значень відповідає або входженню в першому наборі, або коду у другому наборі. Машина бази даних сконфігурована відповідати на код відповідною командою з другого набору записів. Машина бази даних додатково сконфігурована вибирати входження даних з одним або більше значеннями якості на доповнення до одного або більше записів в першому наборі записів і у другому наборі записів. У іншому аспекті даного винаходу наданий інший спосіб генерації звітів. Спосіб включає в себе надання множини полів даних, які редагуються користувачем, що вводить примітки за допомогою пристрою введення, і надання користувачем навігації за допомогою пристрою 1 UA 97803 C2 5 10 15 20 25 30 35 40 45 50 55 60 введення напряму до будь-якого з множини полів даних. Також спосіб включає в себе захоплення приміток за допомогою пристрою введення в форматі бази даних і надання автоматичної звітності за допомогою електронної передачі. Різні аспекти даного винаходу стануть явними і більш зрозумілими з подальшого опису переважних в цей час зразкових варіантів здійснення, які розглядаються разом з прикладеними кресленнями, з яких: Фіг. 1А є загальною діаграмою послідовності операцій з даними для генерації звітів відповідно до одного з варіантів здійснення винаходу. Фіг. 1B є блок-схемою послідовності операцій загального способу генерації звітів відповідно до одного з варіантів здійснення винаходу. Фіг. 2 є діаграмою послідовності операцій з даними при початковому зборі даних при генерації звіту відповідно до варіанта здійснення даного винаходу. Фіг. 3 є діаграмою послідовності операцій з даними при початковій процедурі і введенні відповідно до варіанта здійснення даного винаходу. Фіг. 4 є діаграмою послідовності операцій з даними при необов'язковій другій процедурі і введенні значень відповідно до варіанта здійснення даного винаходу. Фіг. 5 є діаграмою послідовності операцій з даними при генерації фінальних входжень звіту відповідно до варіанта здійснення даного винаходу. Фіг. 6 є діаграмою послідовності операцій з даними при щоденних перенесеннях, включаючи щоденну генерацію звіту і створення резервної копії відповідно до варіанта здійснення даного винаходу. Фіг. 7 є діаграмою послідовності операцій з даними при генерації місячних звітів гарантій якості відповідно до варіанта здійснення даного винаходу. Фіг. 8 є діаграмою послідовності операцій з даними при початковому зборі даних у варіанті здійснення даного винаходу для генерації звіту лабораторних досліджень. Фіг. 9 є діаграмою послідовності операцій з даними при початковому обстеженні патологом у варіанті здійснення даного винаходу для генерації звіту лабораторних досліджень. Фіг. 10 є діаграмою послідовності операцій з даними при лабораторному обстеженні зрізів патологом у варіанті здійснення даного винаходу для генерації звіту лабораторних досліджень. Фіг. 11 є діаграмою послідовності операцій з даними для виписки патологом у варіанті здійснення даного винаходу для генерації звіту лабораторних досліджень. Фіг. 12 є діаграмою послідовності операцій з даними для щоденних перенесень, виконуваних у варіанті здійснення даного винаходу для генерації звіту лабораторних досліджень. Фіг. 13 є діаграмою послідовності операцій з даними в звітах гарантій якості, генерованих у варіанті здійснення даною винаходу для генерації звітів лабораторних досліджень. При використанні в даному документі наступні терміни мають надані нижче визначення при інтерпретації специфікацій і креслень. Користувач означає людину або машину, яка надає введення через пристрій введення. Спостереження включає в себе те, що користувач бачив, визначив або обчислив, використовуючи будь-яке доступне природне, посилене або штучне почуття. Примітки включають в себе спостереження, команди і/або вказівки спостережень і/або команд. Обчислювальна машина включає в себе пристрій, комп'ютер або підключений до мережі пристрій, або комп'ютер, що надає обчислювальні потужності для того, щоб керувати введенням з пристрою введення, витягувати входження з бази даних, сховища або по мережі і/або порівнювати, обчислювати або розраховувати величини, будь-яким способом, основаним на введених або збережуваних величинах, таких як метрики контролю якості. Дані включають в себе один або більше елементів даних, таким чином «дані» - це загальний термін, що належить до одного або більше значень, спостережень або заміток. Команда включає в себе дані, використовувані обчислювальною машиною для вказівки положення в сховищі, параметр рішення і/або зазначення етапів або всього процесу для виконання. Механізм автооновлення включає в себе спосіб оновлення більше ніж одного локального і/або віддаленого запису без втручання користувача. Коли будь-який з пов'язаних записів змінюється, всі пов'язані версії цього запису змінюються за допомогою механізму автооновлення. Механізм автооновлення оновлює тільки в одному напрямі - від змінного входження до пов'язаних входжень. Бази даних можуть включати в себе бази даних у вигляді неструктурованих файлів, багаторівневі бази даних або реляційні бази даних. Входження в базі даних може бути покажчиком на іншу базу даних, це може бути входження даних або код команди, який вказує машині бази даних на необхідність виконання команди на відміну від даних, які вводяться в звіт або шаблон. Як показано на Фіг. 1А, загальна діаграма 100 послідовності операцій одного з варіантів здійснення даного винаходу показує користувача 105, який надає дані, спостереження, 2 UA 97803 C2 5 10 15 20 25 30 35 40 45 50 55 60 примітки, команди і/або інші значення в пристрій 110 введення. Пристрій 110 введення надає дані, спостереження, команди користувача і/або значення обчислювальній машині 115. На доповнення, обчислювальна машина 115 може читати значення з однієї або більше баз 120 даних і/або зовнішніх сховищ 130 даних. Також обчислювальна машина 115 може зберігати дані, спостереження, команди користувача і/або значення в одній або більше базах 120 даних або в одному із зовнішніх сховищ 130 інформації. Обчислювальна машина 115 комбінує користувацьке введення, надане через пристрій 110 введення, з входженнями в базі 120 даних і/або входженнями у зовнішніх сховищах 130 інформації в один або більше звітів 125. Один або більше рецензентів 135, які можуть мати або не мати доступ до зовнішніх сховищ 130 даних, можуть перевіряти звіти 125. Рецензент з числа рецензентів 135 може стати користувачем 105, який генерує один із звітів 125. Потрібно зазначити, що бази 120 даних і/або віддалені сховища 130 даних можуть бути локальними для користувача або бути доступними віддалено за допомогою мережі якого-небудь виду. Пристрій 110 введення може відрізнятися в різних варіантах здійснення даного винаходу. У одному з варіантів здійснення пристрій 110 введення - це пристрій або система запису і розпізнавання мови. Для деяких цілей тиша може бути важливішою, ніж вільні руки. У іншому варіанті здійснення пристрій 110 введення - це реальний або віртуальний сенсорний екран або сенсорна панель, включаючи варіанти з проекцією в простір або на площину. У деяких випадках руками можна ввести більш корисні дані, ніж голосом. У іншому варіанті здійснення пристрій 110 введення - це перо, яке дозволяє малювати на екрані або на поверхні, або інша система розпізнавання рукописного тексту. Також приймаються до розгляду і інші пристрої 110 введення, що буде очевидно фахівцям в даній галузі техніки, які використовують переваги цього розкриття. Відповідно до різних варіантів здійснення даного винаходу пристрій 110 введення - це мікрофон, який передає дані в обчислювальну машину 115 для проведення розпізнавання мови і проведення обчислень в базі даних. Мікрофон повинен бути придатний для розпізнавання мови. У одному варіанті здійснення може бути використаний підвісний мікрофон. У іншому варіанті здійснення може бути використаний головний мікрофон. При бажанні можуть бути використані і інші типи мікрофонів. Повертаючись тепер до Фіг. 1B, на якій показаний загальний спосіб 150 генерації звітів з інтегрованими індикаторами контролю якості. Спосіб 150 починається з користувача, такого як користувач 105 на Фіг. 1А, який одержує запит на генерацію звіту деякого типу, блок 155. У різних типових і ілюстративних варіантах здійснення даного винаходу, звіт може бути звітом патолога про лабораторний зразок або звітом офіцера поліції про дорожній випадок. Потім користувач 105 звертається до шаблона, блок 160. У різних варіантах здійснення даного винаходу обчислювальна машина, така як обчислювальна машина, показана на Фіг. 1А, може мати доступ до будь-якої кількості збережених шаблонів, відповідних будь-якій кількості звітів, які потрібно згенерувати. Користувач 105 може мати доступ тільки до власних шаблонів або користувач 105 може мати доступ до загальних шаблонів, або навіть до шаблонів, доступних всім користувачам даної системи. У одному варіанті здійснення користувач 105 надає зазначення бажаного шаблона обчислювальній машині 115, використовуючи пристрій 110 введення, показаний на Фіг. 1А. Користувач 105 вводить дані, блок 165. В переважному варіанті здійснення користувач вводить дані, використовуючи пристрій 110 введення. У інших варіантах здійснення користувач може вводити дані, використовуючи будь-яку методику або прилад введення. Згідно зі способом 150, обчислювальна машина 115 обробляє дані, заповнюючи шаблон спостереженнями і входженнями з бази даних у відповідь на дані, блок 170. Дані, що вводяться користувачем 105, можуть включати в себе одне або більше значень, спостережень, команд або приміток, які або відомі, або надаються користувачем 105. Спостереження користувача 105 можуть поміщатися обчислювальною машиною 115 в поля в шаблоні. Інші поля в шаблоні можуть бути заповнені обчислювальною машиною 115 входженнями з бази даних. Вибір баз 120 даних, до яких необхідно звернутися, або входжень з даної бази даних, які необхідно додати в шаблон, може бути зроблений на основі даних, наданих користувачем. Також обчислювальна машина додає в шаблон індикатори контролю якості, блок 175. Індикатори контролю якості, що додаються в шаблон постійно або тимчасово, додаються на основі шаблона ί/або полів, заповнених всередині шаблона. Приклади індикаторів контролю якості включають в себе поля з обов'язковою перевіркою помилок, які необхідні для результатів, що зберігаються і/або передаються, поля з обмеженнями входжень, які можуть приймати відповідний набір можливих входжень, і/або описові або кількісні поля. Приклади типів полів для 3 UA 97803 C2 5 10 15 20 25 30 35 40 45 50 55 60 індикаторів контролю якості включають в себе поля статусу, прогнозу, джерела, порівняння, кореляції, посилань, кількісних міток, рекомендованих дій, придатності, придатності вибірки, відліку, причин затримки, ідентифікаційні, індикатора місцеположення, повідомлень, відповідності і часових відміток. Приклади актуальних індикаторів якості звітів по патології включають в себе: стан тканини, код зрізу, прийнятність зрізу, попереднє зіставлення, джерело тканини, початкову оцінку, початкову підозру, враження кореляції, передачу на розгляд в комісію, клітинне зіставлення порівняння цитологічного зрізу зі зрізом тканини, рекомендовану дію, основану на цьому клітинному зіставленні, придатність вибірки для діагнозу, погодження із зовнішнім консультантом, дії за результатами звернення до зовнішнього консультанта, результати, оцінку заморожених зразків, дії, основані на кореляції заморожених зразків з діагнозом, кількість заморожених зразків, час до оцінки заморожених зразків, затримку в оцінці заморожених зразків, дії, основані на затримці, міру відмінності між замороженими зразками і остаточним діагнозом, ідентифікацію патолога, оператора при проведенні дослідження, індикатор останньої сторінки звіту про дослідження, повідомлення патолога про можливу відмінність від клінічного свідчення, ознаку недостатньої прийнятності зразка. Згідно зі способом 150 користувач 105 може закінчити введення і прийняти рішення (в блоці рішення 180) або продовжити додавати введення (повернувшись до блока 165), або згенерувати звіт, блок 185, наприклад, як один із звітів 125 на Фіг. 1А. В деяких варіантах здійснення для деяких шляхів між блоками 165 і 180 обчислювальна машина нічого не додає до шаблона в блоках 170 або 175, коли користувач вводить дані в блоці 165. У деяких реалізаціях блоків 165-180 користувач може надати дані в блоці 165, в той час як обчислювальна машина обробляє дані в блоці 170 без додавання індикаторів контролю якості в блоці 170, або обчислювальна машина може обробляти дані в блоці 170, але не додавати нічого до шаблона в блоці 170, і додати індикатори контролю якості до шаблона в блоці 175. Звіти, згенеровані в блоці 185, можуть бути будь-якого гину. Звіт може бути внесений в базу 120 даних, показану на Фіг. 1А, або у зовнішнє сховище 130 інформації, показане на Фіг. 1А. В деяких варіантах здійснення звіт, згенерований в блоці 185, буде переданий електронним чином рецензенту, такому як один з рецензентів, показаних на Фіг. 1А. Повертаючись тепер до Фіг. 2, ми побачимо, що діаграма 200 послідовності операцій з даними при початковому зборі даних відповідно до одного з варіантів здійснення даного винаходу починається із запиту інформації 205. Запит інформації 205 може включати в себе інформацію, у відповідь на яку користувач 105 надасть спостереження або коментарі. Запит на інформацію 205 може включати в себе також опис людей, місць або спостережуваних предметів, включаючи час спостереження. Запит на інформацію 205 надається в історію 210 входження даних, де користувач 105 може оцінити попередні спостереження і входження, зроблені в минулому. База даних фонової інформації 215 може доповнювати історію 210 входження даних. Історія 210 входження даних і додаткова інформація 215 доступні файлам 220 введення даних для інтеграції. Файли 220 введення даних можуть включати в себе файли даних з будь-якого числа джерел, що належать до спостережень, які проводяться користувачем 105. Файли 220 введення даних також можуть доповнюватися історичною інформацією 225 по справі. Історична інформація 225 по справі може включати в себе історичні дані, які належать до запиту на інформацію 205. Файли 220 введення даних пов'язані таким чином, що оновлювані дані можуть бути надані з даних 230 зовнішнього рецензента. Файли 220 введення даних можуть також приймати записи від стандартних входжень 240 значень код-ім'я і значень 245 код-опис. Файли 220 введення даних генерують звіти 250, використовуючи значення з історії 210 входження даних, фонової інформації 215, історичної інформації 225 по справі, даних 230 зовнішнього рецензента, стандартних величин 240 код-ім'я і/або величин 245 код-опис. Дані зовнішнього рецензента 230 так само як, можливо, і інші дані, переважно оновлюються механізмом 235 автооновлення. Переходячи тепер до Фіг. 3, діаграма 300 послідовності операцій з даними показує початкову процедуру і введення 365, що приймають різні величини з різних джерел. Ці джерела включають в себе фонову інформацію 315 і значення 310 з історії входжень даних. Значення можуть також бути прийняті з історичних файлів 325 по справі. Дані введення можуть бути прийняті від стандартних величин для всіх звітів, включаючи коди контролю якості і величини автоматичного пошуку від входжень 360. Також величини можуть бути прийняті від стандартизованих значень 355 ім'я-код-опис. Інтеграція величин в початкову процедуру і введення 365 переважно відбувається за допомогою кодів користувацького введення. У одному варіанті здійснення операції на Фіг. 2 і Фіг. 3 виконуються окремо. У цьому варіанті здійснення операції на Фіг. 3 ідуть за операціями на Фіг. 2, а потім операції на Фіг. 4 або Фіг. 5. У 4 UA 97803 C2 5 10 15 20 25 30 35 40 45 50 55 60 цьому варіанті здійснення в процесі або після операцій на Фіг, 2 і операцій на Фіг. 3 можуть створюватися окремі файли журналів. У іншому варіанті здійснення операції на Фіг. 2 і Фіг. 3 виконуються паралельно. У паралельному варіанті здійснення спосіб переміщається від паралельних операцій на Фіг. 2 і Фіг. 3 прямо до операцій на Фіг. 4 або Фіг. 5. У цьому паралельному варіанті здійснення в процесі або після операцій Фіг. 2 і Фіг. 3 можуть створюватися об'єднані файли журналів. На Фіг. 4 зображена діаграма 400 послідовності операцій, яка показує введення для опціональних повторних процедур 480. У загальному випадку для ініціалізації повторної процедури 480 надаються величини з початкової процедури 465. Зазначимо, що початкові процедури, як правило, надаються механізмом 475 автоперенесення даних в значення другої процедури 480. Як і початкова процедура 365, показана на Фіг. 3, повторна процедура 480, показана на Фіг. 4, може приймати дані, що вводяться, з історії 410 входжень даних і фону 415. Входження можуть бути одержані з історичних файлів 425 по справі і/або даних 430 зовнішнього рецензента. Дані 430 зовнішнього рецензента, як правило, надаються з використанням механізму 435 автооновлення, який надає повторній процедурі 480 нові або оновлені величини з пристрою зберігання, такого як одне із зовнішніх сховищ 130 інформації, показаних на Фіг. 1А. Стандартні величини 455 ім'я-код-коментар також надаються повторній процедурі 480, звичайно на основі вказівок, наданих користувачем 105 як дані, такі як в блоці 170, показаному на Фіг. 1B. Стандартизовані величини для всіх відповідей і коди гарантій якості і автоматичний пошук 460 надаються повторній процедурі 480 на основі автооновлення 470. Величини від повторної процедури 480 можуть також зберігатися як стандартні величини 460. Початкова процедура 465 і повторна процедура 480 можуть використовуватися для генерації одного або більше періодичних звітів 450. На Фіг. 5 зображена діаграма 500 послідовності операцій з даними при генерації остаточних входжень звітів, остаточних кодів контролю якості і коментарів 590. У загальному випадку, величини з повторної процедури 580 і/або початкової процедури 465 надаються для ініціалізації остаточних входжень 590 звіту. Ці величини, в загальному випадку, надаються механізмом 585 автоперенесення даних. Як показано в попередніх Фіг. 3 і 4 історія 510 входження даних і фонова інформація 515 можуть бути надані для генерації остаточних входжень 590 звіту. Історичні файли 525 по справі можуть надаватися у входження 590 остаточного звіту. Дані 530 рецензента можуть надаватися механізмом 535 автооновлення входженням 590 остаточного звіту. Як і вище стандартні величини 555 ім'я-код-опис можуть надаватися входженням 590 остаточного звіту, звичайно на основі користувацьких вказівок в командах. Стандартизовані величини для всіх звітів, коди гарантій якості і величини 560 автопошуку можуть надаватися входженням 590 остаточного звіту через механізм 570 автооновлення. Входження остаточного звіту можуть також зберігатися у вигляді стандартних величин для всіх звітів 560. Після прийому щонайменше вказівки запиту на автоматично генерований звіт система може бути сконфігурована автоматично посилати через електронне виведення 595 звіт з електронним підписом людини, яка заповнила справу. Звіт переважно відповідає всім регулюючим вимогам. Електронний інтерфейс 595 переважно автоматично вставляє номер факсу подавця(ів) в справі і посилає йому звіт. У випадку, якщо раніше справа відправлялася по факсу, інтерфейс здатний визначити, чи має подавець(і) правильний і підтверджений ним номер факсу, після чого послати факс тільки тим подавцям, які хочуть цього. У випадку, якщо справа раніше вже посилалася, але через якісь причини подавець не одержав його, є функція, яка дозволяє проте негайно повторно послати факс. Інтерфейс 595 може бути активований запрограмованим голосовим макросом, макросом клавіатури, пристроєм введення або виконанням підпрограми, яка запускається в кінці дня. Підпрограма може бути застосована до існуючої справи, до всіх заповнених справ, вибірково користувачем до справ, заповнених користувачем, а також до будь-якого діапазону справ. Додатково всі подавці одержують повідомлення про випадки, коли справа затримується довше стандартного часу, включаючи демографічігу інформацію, інформацію про зразок, дату, коли справа була одержана, і причину, по якій справа затримується. У випадку множини подавців, кожний з них одержить факс, якщо для цього подавця вказаний правильний номер факсу. Переходячи тепер до Фіг. 6, ми побачимо діаграму послідовності операцій з даними, на якій показані періодичні перенесення, відповідно до одного з варіантів даного винаходу. Перевірки 610 періодичних перенесень обмінюються за допомогою періодичних файлів 605. Періодичні файли 605 використовуються для генерації періодичних звітів 650 керування якістю і, як правило, надаються механізмом 655 автоперенесення даних в стандартизований файл 5 UA 97803 C2 5 10 15 20 25 30 35 40 45 50 55 60 користувача з типом 660 звіту, а також в історичні файли 625. Періодичні файли 605 також використовуються для оновлення користувацьких стандартизованих файлів для всіх значень 665 звіту, як правило, через механізм 655 автоперенесення даних. Користувацькі стандартизовані файли з типом 660 звіту можуть також використовуватися для оновлення основного стандартизованого файла 670. Історичні файли 625 можуть включати в себе місячні файли 630 справ, річні файли 635 справ і історичні файли 640 справ. Періодичні файли 605 і історичні файли 625 можуть надаватися і зберігатися як файли 615 архівів, фонових історичних файлів 645 і/або історичних файлів 620 рецензента. Переходячи тепер до Фіг. 7, ми побачимо діаграму 700 послідовності операцій з даними при генерації звітів контролю якості відповідно до одного з варіантів даного винаходу. Дані з місячних історичних файлів 705 включаються в місячні файли гарантій якості 715. Місячні файли гарантій якості 715 використовуються для порівняння, перевірки цілісності і аналізу 720. Історичні файли гарантій якості 725, як правило, надаються через механізм 710 автоперенесення разом з порівняннями, перевірками цілісності і аналізом 720 для генерації звітів 750, які можуть бути згенеровані по категоріях. Категорії генерованих звітів гарантій якості можуть бути визначені або користувачем, або системою. Приклади звітів гарантій якості включають в себе перевірку статусу, перевірку достовірності прогнозу, ефективність і/або точність/надійність користувача. У різних варіантах здійснення може бути згенерований окремий звіт для кожного індикатора контролю якості. У інших варіантах здійснення звіти можуть генеруватися на основі перехресної кореляції між або серед множини індикаторів контролю якості. Переходячи до Фіг. 8-13, представлений детально варіант здійснення генерації звіту лабораторних досліджень. Загалом процес полягає в тому, що лабораторія лікарні переглядає всі тканини, що надходять в лікарню з різних джерел. Джерелом може бути хірургічна операція, біопсія або обстеження. Якою б ні була тканина, всі взяті зразки проходять через лабораторію патологій. Все, що було переглянуто в лабораторії, потрібно описати в звіті. Звіти пишуться на різних стадіях обстеження. Наприклад, записуються результати початкового обстеження для первинних аналізів тіла, зрізу і т. п. Тканина може бути відіслана для спеціального вивчення. Персонал, який виконує спеціальне вивчення, може провести власне внутрішнє фарбування або інші процедури над посланими для спеціального вивчення зразками. У всіх випадках вони готують поперечні зрізи для дослідження під мікроскопом. Після того, як це зроблено, патолог досліджує поперечні зрізи і готує інший звіт. Після того, як другий звіт буде готовий, патолог сформує діагноз. Звіт з діагнозом буде заповнений, зареєстрований і відправлений відповідному терапевту. Іноді звіт такий, що діагноз неточний. Це може бути важким випадком. Справа може бути відправлена на зовнішню консультацію або на консультацію з будь-ким, щоб одержати другу або третю думку. Якщо запитана зовнішня консультація, то випускається додатковий звіт. Відповідно до різних варіантів здійснення даного винаходу на всіх стадіях є різні бази даних, використовувані для відстеження кожного з різних звітів. По мірі просування справи через кабінети лікарів звіти можуть переноситися з однієї бази даних в інші. Історичний запис про звіт може знаходитися в місячному файлі, річному файлі або в історичному файлі. Місячний файл справи, як правило, має звіти контролю якості і гарантій якості, виконувані за його даними. Існує множина різних звітів, які залежать від виду зрізу або зразка, або специфічного досліджуваного предмета, від якості препаратів, якості аналізу, якості зовнішніх консультацій. Звіти включають в себе такy інформацію як час обробки справ, якість обстежень, якість початкового діагнозу практикуючого терапевта проти побаченого патологом. Кожна множина входжень, кожний шаблон, кожний звіт і кожне входження кожного шаблона переважно є окремою базою, при цьому бази даних пов'язані унікальним ідентифікатором. Бази даних і їх відповідні структури і конфігурації, описані тут, є зразковими і ілюсіративними, і інші бази даних і структури баз даних і конфігурації можуть бути використані при бажанні. Наприклад, може бути використана єдина консолідована база даних. Бази даних оновлюються з кожним новим звітом як для повноти, так і для того, щоб патолог мав історію, денну, місячну, річну і особисту, для всіх зроблених звітів. Кожний патолог має стандартну базу даних для кожного поля, а також існує окрема база даних для кожного патолога. Денний файл справ може бути використаний всіма, хто користується системою. Кожний патолог може мати відмінне представлення денного файла справ. Тобто кожний патолог може переглянути денний файл справ, використовуючи одну і ту ж базу даних, але з іншим екраном, який ідентифікує патолога. Кожний патолог може мати свої власні стандартні 6 UA 97803 C2 5 10 15 20 25 30 35 40 45 50 55 60 файли, таким чином, шукаючи стандартну справу, використовувати свої власні стандартні справи. Також є основний стандартний файл, який містить всі стандартні справи, і якщо патолог зустрінеться зі справою, відсутньою в файлі стандартних справ, то він може звернутися до основного файла стандартних справ, щоб визначити, яку справу використовувати. За допомогою диктування даних і голосових команд, дані поміщуються в правильні поля, зберігаються в базі даних для визначеного пацієнта і визначеної тканини, незалежно від того, чи було обстеження грубим або мікроскопічним, чи були виконані дії постановкою діагнозу або консультацією, чи вимагає діагноз змін або здійснювався ряд обстежень. Кожний діагноз може генерувати окремий білінговий код. Система автоматично фіксує дату і час кожного входження. Основні демографічні дані пацієнта можуть бути внесені автоматично. Щоденні звіти можуть друкуватися автоматично. Щомісячні звіти гарантій якості можуть друкуватися автоматично. У кінці місяця дані можуть переноситися у відповідні файли, можуть виконуватися розрахунки, друкуватися звіти, проводитися аналіз, і місячні звіти гарантій якості можуть навіть переноситися в лікарню напряму, таким чином, в лікарні буде наявна інформація про параметри гарантій якості кожного патолога, який там працює. Білінгові коди можуть генеруватися автоматично по типу і номеру дослідженого зразка. Якщо під час обстеження потрібне проведення додаткових процедур, аналізів зразків, спеціальної обробки зразків, то в цьому випадку також автоматично надаються коректні білінгові коди (correct billing codes, СРT). Кожний білінговий код пов'язаний з конкретною справою і може бути розпечатаний разом з інформацією про неї або за необхідності переданий електронним чином в білінговий сервіс або інший білінговий звіт. Ця процедура дозволяє білінговим кодам автоматично співвідноситися з відповідною справою для подальшого перегляду або за необхідності аудиту. На доповнення це гарантує точне і своєчасне виставлення рахунків пацієнтам відповідно до законодавчих модифікацій або обмежень. За необхідності білінгові коди можуть бути розпечатані разом із заповненим звітом і передані електронно, включаючи автофакс, за необхідною адресою для виставлення рахунків. Відповідно до ілюстративного варіанта здійснення генерації звітів лабораторних досліджень, починаючи з Фіг. 8, спосіб починається з операції збору даних 1200. Запит 1205 лабораторного зразка може включати в себе інформацію про пацієнта і описи зразка для використання патологом. Дані в запиті 1205 лабораторного зразка надаються або інтегруються з журналом 1210 гістології. Журнал 1210 гістології може включати опис і кількість всіх зразків і зрізів, обстежених патологом в даній групі, організації, лікарні і т. д. Демографічні дані 1215 пацієнта можуть включати в себе ім'я, дату народження, стать, лікарню, білінгові номери, номер кімнати і т. д. Демографічні дані 1215 пацієнта надаються журналу 1210 гістології, а також журналам 1220 файлів зразків. Всі файли зразків від терапевтів лікарні, зовнішніх терапевтів і терапевтів медичних груп знаходяться всередині журналів 1220 файлів зразків. Історична інформація 1225 по справі, яка може включати в себе номери справ, демографічну інформацію, зразки, опис і дані діагностики, як правило, автоматично зв'язується з журналами 1220 файлів зразків через номер рахунку або ім'я. Інформація 1230 терапевта, яка може включати в себе код, галузь медицини і номери телефонів, звичайно за допомогою пошуку по імені, також надається в журнали 1220 файлів зразків. Назва тканини, стандартизовані назви і коди 1240А місць включаються в журнали 1220 файлів зразків, звичайно відповідно до команд користувача, що вводяться. Стандартизований опис типу тканини і коди 1240В і стандартизовані описи 1240С зразків також інтегруються в журнали 1220 файлів зразків, звичайно відповідно до команд користувача, що вводяться. Можуть бути згенеровані журнали 1210 приготування зразків і гістології. Початковий журнал автоматично витягує демографічні дані пацієнта на основі раніше призначеного лікарняного ідентифікаційного номера пацієнта. Журнал також дозволяє автоматично витягувати історичну інформацію попередніх справ за допомогою вищезазначеного лікарняного ідентифікаційного номера. Якщо ідентифікаційний номер не існує, доступна функція пошуку для обстеження попередніх справ на ім'я пацієнта і витягання даних, відповідних поточному пацієнту. Розташування і тип зразка вводяться за допомогою пошуку в стандартний патологічний опис, який пов'язаний з відповідними (СРТ) білінговими кодами. Ця інформація журналу переноситься в початкові дані обстежень справи для патолога і зберігається в гістологічних базах для подальшого використання. Кількість блоків для кожного зрізу автоматично розраховується по типах зразка і бажаних зрізах в патологічному обстеженні. За необхідності призначення блоків може бути відмінене патологом, який обстежує. Зв'язок між обстеженням заповненої справи і гістологічним журналом підтримується за допомогою автоматично генерованого номера справи і дозволяє відправляти інформацію про якість зразка із заповненої справи зворотно в файл журналу для подальшого огляду і звітності. 7 UA 97803 C2 5 10 15 20 25 30 35 40 45 50 55 На Фіг. 9 показана діаграма 1300 послідовності операцій з даними при початковому обстеженні патологом варіанта здійснення генерації звіту лабораторного дослідження відповідно до даного винаходу. Генерація щоденного початкового обстеження 1365 включає в себе використання пристрою 110 введення, який може включати в себе введення під диктування, голосове введення, введення з клавіатури інформації про візуальне обстеження одного або більше зразків. Журнальні файли 1220 зразків включаються в щоденне початкове обстеження 1365. Демографічна інформація 1215 про пацієнта може бути включена в щоденне початкове обстеження 1365. Дані гістологічного журналу 1210 можуть бути включені в щоденне початкове обстеження 1365. Файли 1225 з історичною інформацією по справі, дані 1230 терапевта і назви 1240А тканин також можуть бути включені в щоденне початкове обстеження 1365. Дані 1230 терапевта переважно поповнюються новою і переглянутою інформацією через механізм 1330 автооновлення, таким чином щоденне початкове обстеження 1365 завжди є актуальним. Стандартизовані коди 1340В розташування областей тканини і стандартизовані коди 1340С назв захворювань також можуть бути включені в щоденне початкове обстеження 1365. Стандартизовані файли 1320 обстежень включаються в щоденне початкове обстеження 1365, переважно механізмом автоперенесення. Файли 1340А стандартизованих описів новоутворень і білінгових кодів можуть включатися в щоденне початкове обстеження 1365. На Фіг. 9 включення переважно виконується по команді або вказівці користувача. На Фіг. 10 показана діаграма 1400 послідовності операцій з даними при обстеженні зрізу патологом при генерації звіту лабораторних досліджень відповідно до одного варіанта здійснення даного винаходу. Генерація щоденного дослідження препарату 1480 включає в себе користувача 105, що використовує пристрій 110 введення, який може включати в себе диктофон, клавіатуру або пристрій голосового введення для опису одною або більше візуальних обстежень одного або більше зразків. Щоденне початкове дослідження 1365 включається в щоденне обстеження препаратів. Щоденне початкове обстеження 1365 передається в щоденне обстеження зрізів за допомогою механізму 1465 автоперенеcення. Демографічна інформація 1215 про пацієнта може бути включена в щоденне обстеження 1480 зрізів. Гістологічний журнал 1210 може бути також включений в щоденне обстеження 1480 зрізів. Файли 1225 з історичною інформацією по справі, дані 1230 терапевта і назви 1240А тканин також можуть бути включені в щоденне обстеження 1480 зрізів. Дані 1230 терапевта переважно поповнюються новою і переглянутою інформацією через механізм 1330 автооновлення, таким чином щоденне обстеження 1480 зрізів завжди містить актуальну інформацію. Стандартизовані коди 1340В розташування областей тканини і стандартизовані коди 1340С назв захворювань також включаються в щоденне обстеження 1480 зрізів, як правило, по введеній користувачем команді. Стандартизовані файли 1320 обстежень включаються в щоденне обстеження 1480 зрізів, як правило, механізмом 1420 автоперенесення даних. Зазначимо, що щоденне обстеження 1480 зрізів може повторно включатися в стандартизовані файли 1320 обстежень. Файли з кодами новоутворень, особливих плям і білінговими кодами для запиту додаткових аналізів, білінгу пацієнтів і гарантій якості 1440 переважно включаються в щоденне обстеження 1480 зрізів. На Фіг. 11 показана діаграма 1500 послідовності операцій з даними при виписці патолога при генерації звітів лабораторних досліджень відповідно до одного варіанта здійснення даного винаходу. Щоденне обстеження 1480 зрізів надається для виписки 1590 патолога за допомогою механізму 1580 автооновлення. Демографічна інформація 1215 про пацієнта може бути включена у виписку 1590 патолога. Файли 1225 з історичною інформацією по справі, дані 1230 терапевта, стандартизовані коди і назви 1240А тканин також можуть бути включені у виписку 1590 патолога. Дані терапевта, як правило, оновлюються через механізм 1330 автооновлення, таким чином виписка 1590 патолога завжди містить найбільш актуальну інформацію. Стандартизовані коди 1340В розташування областей тканини і стандартизовані коди 1340С назв захворювань також включаються у виписку 1590 патолога, як правило, по введеній користувачам команді. Файли 1440 новоутворень, особливих плям і файли з білінговими кодами також, як правило, включаються за допомогою командних кодів у виписку 1590 патолога. Стандартизовані файли 1320 обстежень автоматично надаються за допомогою механізму 1420 автооновлення у виписку 1590 патолога. Значення виписки 1590 патолога можуть повторно включатися в стандартизовані файли 1320 обстежень. Виписка 1590 патолога повинна включати в себе входження з діагнозом і коментарі і коди остаточної перевірки якості. Після одержання щонайменше індикації запиту на автоматично генерований звіт система може бути автоматично сконфігурована автоматично посилати через факсимільне виведення 595 звіт з електронним підписом людини, яка заповнила справу з діагнозом. Звіт переважно відповідає всім регулюючим вимогам, таким як НІРАА. Факсимільний інтерфейс автоматично 8 UA 97803 C2 5 10 15 20 25 30 35 40 45 50 55 60 вставляє в заповнену справу номер факсу терапевта(ів), що подав, і посилає звіт терапевту(ам), що подав. У випадку, якщо раніше справа відправлялася по факсу, інтерфейс здатний визначити, чи мають терапевти, що подали, правильні і підтверджені ним номери факсів, після чого послати факс тільки тим терапевтам, які хочуть цього. У випадку, якщо справа раніше вже посилалася, але через якусь причину терапевт не одержав його, є функція, яка дозволяє негайно переслати факс ще раз. Інтерфейс може бути активований запрограмованим голосовим макросом, клавіатурним макросом, пристроєм введення або виконанням підпрограми, що запускається в кінці дня. Підпрограма може бути застосована до існуючої справи, до всіх заповнених справ або вибірково до справ, заповнених користувачем. Користувачі можуть автоматично вибирати свої власні звіти або всі заповнені звіти для відправлення по факсу. Додатково всі терапевти, що подали, одержують повідомлення про випадки, коли справа затримується довше стандартного часу, включаючи демографічну інформацію справи, інформацію про зразок, дату, коли справа була одержана, і причину, по якій справа затримується. У випадку наявності у справи декількох терапевтів, що подали, кожний з них одержує факс, якщо для цього одержувача вказаний правильний номер факсу. Справи, які вже були відправлені по факсу, помічаються для уникнення численних передач однієї і тієї ж справи до завершення. За необхідності справа може передаватися повторно по запиту будь-яких додаткових терапевтів, що беруть участь, або тих, кому воно було раніше послане. Передача завершується розрахунком зв'язків між терапевтами, що беруть участь, працюючими над цією справою, окремим файлом даних, що містить інформацію про маршрутизацію передачі, і запрограмованими зв'язками, вбудованими в звіти для передачі правильних інструкцій по набору і/або маршрутизації для факс-сервера або іншого електронного пристрою. На Фіг. 12 зображена діаграма 1600 послідовності операцій з даними при щоденних перенесеннях даних для цілей гарантій якості. Щоденні файли 1605 справ як правило включають в себе результати всіх обстежень патолога, перевірок якості, кодування гарантій якості і білінгову інформацію. Перевірки 1610 перенесення даних виконуються обчислювальною машиною для перевірки виконання кодування гарантій якості, коректності дат і перевірки заповнення всіх справ, які були в запиті патолога. Щоденний файл 1605 справ обмінюється даними з базою 1610 даних перевірок перенесення даних. Щоденні звіти 1450 можуть генеруватися автоматично з щоденних файлів 1605 справ за допомогою механізму 1655 автооновлення. Щоденні файли 1605 справ надаються в стандартизований файл 1660 обстежень терапевта. Стандартизований файл 1660 обстежень терапевта може містити початкові і кінцеві замітки лікаря і коди гарантій якості. Всі щоденні файли справ можуть бути перетворені в стандартний шаблон для подальших обстежень для додавання в стандартизований файл 1660 обстежень. Зазначимо, що інформація з щоденних файлів 1605 справ може також надаватися в стандартну резервну копію стандартизованого файла 1665 обстежень терапевта. Стандартизований файл 1660 обстежень терапевта може також використовуватися для оновлення основного стандартизованого файла 1670, який містить стандартні шаблони терапевта. Щоденні файли 1605 справ надаються і включаються в файли 1225 з історичною інформацією по справах, включаючи один або більше місячних файлів 1630, річних файлів 1635 і історичних файлів 1640. Кожний з місячних файлів 1630 включає всі результати обстежень патолога, перевірки і коди гарантій якості і білінгову інформацію за місяць. Місячні файли 1630 справ використовуються для місячних звітів гарантій якості. Кожний з річних файлів 1635 включає всі результати обстежень патолога, перевірки і коди гарантій якості і білінгову інформацію за рік. Файл з історією 1640 справ включає всі результати обстежень патолога за всі часові періоди, всі перевірки гарантій якості і всі коди і білінгову інформацію. Також може бути створений резервний річний файл 1615 справ для цілей резервування. Може бути також створений файл історії імен з демографічними даними 1645 пацієнтів. У файл 1620 з історією справ лікарні можуть додаватися всі справи даної лікарні. На Фіг. 13 показана діаграма 1700 послідовності операцій з даними при генерації звітів гарантій якості у варіанті здійснення генерації звіту лабораторних досліджень. Місячні файли 1630 справ включаються в місячні файли гарантій якості для лікарні, зовнішньої медичної групи, терапевта і т. д. 1715. Переважно значення переносяться за допомогою механізму 1710В автоперенесення даних. Місячний файл 1630 справ також включається в історичні файли 9 UA 97803 C2 5 10 15 20 25 30 35 40 45 50 55 гарантій якості для лікарні, зовнішньої медичної групи, терапевта і т. д. 1725 за допомогою механізму 1710А автоперенесення даних. Місячні файли 1715 гарантій якості можуть включати одну або більше з наступних труп, зображених на 1720: порівняння діагнозів, обстеження грудей, якості зразків, кореляцію тканин, порівняння заморозок, клітинні порівняння, якості зрізів, час зберігання, оцінки власних терапевтів, оцінки зовнішніх консультантів. Ці групи є тільки ілюстративними і зразковими, можуть бути включені також і інші групи. Місячні файли 1715 гарантій якості, включаючи підмножини у 1720, використовуються для генерації звітів гарантій якості 1715 для будь-якої однієї або більше з підмножин, що включають порівняння діагнозів, обстеження грудей, якості зразків, кореляцію тканин, порівняння заморозок, клітинні порівняння, якості зрізів, час зберігання, оцінки власних терапевтів, оцінки зовнішніх консультантів. Ці звіти по якості є тільки лише зразковими і ілюстративними і при бажанні можуть бути сформовані інші звіти. Відповідно до різних аспектів даного винаходу патолог може вводити дані негайно після виконання огляду. Патолог може вводити дані для конкретної справи, і система може створювати звіт в кінці дня, в кінці місяця або в будь-який час, що буде основою для гарантій якості будь-яких патологічних зразків, які проходять через лікарню або лабораторію. Американська Колегія патології (College of American Pathology, CAP) вимагає, щоб десять процентів всіх справ були переглянуті, але не вказує, які саме десять процентів або як необхідно переглядати. CAP вимагає, щоб рецензент указав, які справи були переглянуті і наскільки вони відповідають звичайним очікуванням. Якщо переглянуті справи не відповідають звичайним очікуванням, то звіт повинен пояснювати, чому вони не відповідають очікуванням, і чи не зробило це серйозного ефекту на пацієнта. Коли гарантії якості виконуються заднім числом, пропускається багато даних. Дуже важко пройти через всі матеріали в зворотному порядку і витягнути інформацію, яка буде корисна для поліпшення якості системи аналізу патології. Ретроспективний перегляд витягує тільки невелику частку справ, представляючи частку виконаної роботи. Відповідно до різних варіантів здійснення даного винаходу до 100 процентів оброблюваних справ за до 100 процентів часу можуть бути рецензовані на постійній основі. У одному з варіантів рецензується до 90% всіх справ. Гістологія - це підготовка зрізів і підготовка матеріалів. Патолог бере сиру тканину, таку як, наприклад, тканина грудей, бере шар тканини і потім за допомогою визначеного процесу поміщає тканинy на скляне предметне скло. Потім тканина обстежується під мікроскопом. У процесі підготовки тканини до поміщення на скло проводиться її фарбування. Один із звітів гарантій якості потрібен для визначення якості процесу фарбування. При виконанні щоденного початкового обстеження 1365 або щоденного обстеження 1480 зрізу або виписки 1590 патолога користувач 105, в цьому випадку патолог, викликає стандартний шаблон для конкретного звіту, який необхідно заповнити. Шаблон може братися або з особистої бібліотеки шаблонів патолога, або з бази загальних стандартних шаблонів. Переміщення між входженнями в шаблоні виконується за допомогою голосових або будь-яких інших команд через пристрій 110 введення, показаний на Фіг. 1А. В одному з варіантів здійснення даного винаходу, в середині звіту зроблені нові місця входжень, а місця входжень на початку і в кінці звіту встановлені незмінними. Як приклад спостережень, які використовують як дані, так і команди, розглянемо макроскопічне обстеження тканини. Голосова команда, яка позначає, що відбувається макроскопічне обстеження, викличе шаблон для макроскопічного обстеження. Друга голосова команда може вказувати на складену біопсію, таку як біопсія шлунка і біопсія прямої кишки. Голосова команда вносить дані для описів, необхідних для макроскопічного обстеження для складеної біопсії шлунка і прямої кишки, на основі даних і команд. Якщо наприклад в шлунку є хронічний гастрит або середній хронічний гастрит, то макрос бази даних внесе необхідний опис на основі короткої голосової команди, а також введе додаткові записи, які повинні бути виконані. Якщо в прямій кишці є, наприклад, поліпи, і не є стандартного шаблона для поліпів прямої кишки, але є для товстої кишки, то в цьому випадку може бути викликаний шаблон для товстої кишки, модифікований і збережений у вигляді макроса для поліпів прямої кишки. Також записи бази даних можуть включати білінгові коди. Файли, звіти і інші входження можуть автоматично імпортувати білінгові коди у відповідь на значення даних, що вводяться в звіти, і/або команди всередині даних, що вводяться в звіти. Як приклад механізму гарантій якості, який може бути автоматично застосований до звіту без додатковою введення, необхідного від патолога або користувача, розглянемо патологічний звіт, в якому відсутня історія пацієнта. Звіт гарантій якостей для дня, місяця або року або для будь-якого значення 10 UA 97803 C2 5 10 15 20 25 30 35 40 45 50 55 60 історії для даної групи патологів або для госпіталю автоматично підсвітить входження, в якому відсутня історія пацієнта. Дані по гарантії якості можуть вводитися особисто, можуть вводитися автоматично обчислювальною машиною або можуть автоматично проставлятися так, як, наприклад, помітки часу початку або закінчення звіту і т. д. Розглянемо також випадок, коли потрібне клітинне порівняння з тканиною, яка надійде пізніше. Звіт контролю якості може показати, чи узгоджуються клітинний звіт і біопсія тканини. Якщо проводяться зовнішні консультації або справа посилається ще кудись, звіт контролю якості може показати, чи узгоджується зовнішній діагноз з діагнозом, виконаним першим патологом. Звіт по якості може показати, чи узгоджується діагностика замороженої тканини у випадку, якщо діагностика замороженого зрізу порівнюється з діагностикою, виконаною пізніше. У іншому прикладі CAP вимагає дані «cytosource» і «cytotype», наприклад, для звіту про те, скільки зрізів було проаналізовано патологом для негінекологічної цитології. Патологи, як правило, обмежені максимум в 100 цитологічних зрізів на день. Щоденні звіти визначають точно, скільки зрізів було вивчено патологом. Наступне - конкретне здійснення даного винаходу для генерації звітів лабораторних досліджень зі статистичним звітом-доповненням на щонайменше щоденній і щомісячній основі. Вся методологія забезпечує акуратність і якість звітності. Широко використовуються стандартизовані шаблони справ, основні файли даних пацієнтів і терапевтів, для гарантій цілісної і повторюваної звітності обстежень по справах. Починаючи з 1990, в реляційних базах даних є 100% контроль гарантій якості всіх досліджень патології, який дозволяє швидку і всебічну звітність і аналіз справ. Надмірність даних забезпечується за рахунок використання щоденного резервування в декілька місцеположень, резервування даних під час важливих щоденних операцій, що включають перенесення даних з різних файлових структур і множини файлів з одними і тими ж даними. Множина файлів включає в себе місячні, річні і історичні архіви, вони використовуються не тільки для резервування, але також і як джерела даних для щоденного, щомісячного і щорічного контролю гарантій якості і статистичного аналізу. Всі денні справи друкуються і посилаються по факсу або іншим методом терапевтам, що беруть участь, для заповнення. Крім того, справи можуть друкуватися по конкретних справах, по медичній групі, по конкретному терапевту, персоналу, патологу або помічнику, конкретній даті або діапазону дат з поточного або попередніх років, і кількість копій дослідження може варіюватися залежно від бажання медичної групи або терапевтів, що беруть участь. Ефективність дії забезпечується можливістю введення даних, команд навігації, вибору даних і вибору полів і/або входжень даних, як з клавіатури, так і голосом. Для одержання даних, пошуку даних, запитів на друк, розрахунку полів і пошуку і т. д. широко використовуються макроси, як з клавіатури, так і голосові. Стандартизовані звіти по обстеженнях можуть бути витягнуті в поля для обстежень без повторного введення. Однократне введення даних суміщене з автоматичним перенесенням даних з одного джерела у множину різних файлових структур з ідентичними іменами полів. Автоматичний пошук даних основується на приведенні у відповідність інформації в полях файла обстеження і основного файла. Обчислення в полях основані на вже введених даних обстеження і/або стандартних величинах. Ручний пошук інформації у великих основних файлах, таких як демографічні дані пацієнтів, використовується для одержання інформації по невідомій справі. Після того, як вводиться або вимовляється перший символ, відповідне значення майже вмить показується з основного файла (навіть при сотнях і тисячах записів в основному файлі). По мірі того, як вводяться подальші букви, пошук продовжуєтьсядоти, поки потрібна інформація не буде знайдена. Одночасно показується множина записів з основного файла, для вибору потрібного запису можна використовувати кнопки перегортання сторінок і керування курсором або голосове керування. Потім необхідна інформація з основного файла автоматично вставляється в файл з обстеженням. Шукана інформація, тобто ім'я, не обов'язково повинна бути значенням, що вставляється в поле обстеження. Такий код як номер пацієнта для цього пацієнта може бути витягуваною величиною, потім цей код буде основою для автоматичного одержання з основного файла іншої інформації, яка належить до справи, без виконання пошуку. Поля для вибору мають обмежене число прийнятних значень, наприклад, ім'я патолога. Коли користувач переходить до введення даних в ці поля, на екрані показуються (випадаючим списком) доступні значення, і користувач може вибрати значення тільки з них. Заповнені записи переносяться щоденно підряд з кожного файла. Щоденно журнали зберігаються в файлах журналів. Перенесення основане на діапазоні дат, але, як правило, це поточна дата. Вся загальна інформація переноситься щоденно в файл обстежень, інформація резервується і потім видаляється, чекаючи нової інформації з файлів журналів. Щоденні 11 UA 97803 C2 5 10 15 20 25 30 35 40 45 50 55 60 обстеження і місячні звіти чекають місячних звітів з контролю і аналізу гарантій якості. Річні звіти по справах підготовлюються або автоматично, або по запиту. Є історичний архів всіх справ. Заповнені справи передаються щоденно з файла обстежень в місячний, річний і архівний файли. По завершенню щоденного перенесення створюється резервна копія денного файла, і інформація по завершених справах видаляється з денного файла, поміщуючи справи в режим очікування доти, поки не буде готова додаткова інформація або перевірка. Опис файлів пацієнта включає в себе демографічну інформацію про пацієнта, яка переноситься з файлів лікарні (або клініки і т. д.), включаючи ім'я, номер лікарні, номер пацієнта, вік, дату народження і дату надходження в лікарню. Автоматичним пошуком на основі номера пацієнта, використовуваного для одержання інформації з демографічного файла, створюються журнальні дані про пацієнта, які включають в себе наступну інформацію: номер справи і дата обстеження, демографічна інформація. Інформація про терапевта, що бере участь, включає ручний вибір імені з файла терапевта, автоматичне одержання коду діагнозу, автоматичне одержання коду походження (визначення місцеположення практики терапевта, наприклад, хірургія, акушерство і гінекологія, ендоскопія і т. д.), автоматичне одержання номера факсу. Інформація про справу включає в себе кількість заморожених зрізів, тип, джерело і кількість клітинних зрізів, номер попереднього обстеження для даного пацієнта, що міститься в історичних архівах, з ручним вибором імені пацієнта і дати народження, використовуваних для пошуку людей і одержання відповідних номерів справ і клітинних даних (якщо є). Клітинні дані включають в себе тип зразка (наприклад, цереброспінальна рідина, мокротиння і т. д.), джерело тканини або субстанції (наприклад, нирка, легеня, печінка і т. д.), і кількість зрізів. Інформація про зразок (або зразки, наприклад, до дванадцяти або іншої кількості, якщо необхідно, зразків) включає в себе: джерело тканини або речовини (наприклад, нирка, грyдна клітка і т. д.) з інформацією, одержаною з основного файла з найменуваннями тканин, для забезпечення стандартизованих і акуратних звітів, положення з використанням вільного текстового опису, основаного на реальних зразках, тип зразка (наприклад, змив, біопсія, рідина, сегмент і т. д.) і автоматичний опис зразка, оснований на інших входженнях. Файл з макроскопічним дослідженням включає всі дані, передані з файла журналів, плюс результати первинного візуального обстеження тканини або субстанції пацієнта, переданих терапевтом(ами), що бере участь. Інформація про справу пацієнта з архівних справ під номерами, введеними вище, автоматично друкується і стає доступною патологу, який виконує обстеження. По завершенню первинного обстеження щоденних справ, перенесених з файла журналу, інформація по кожній справі переноситься в денний файл обстежень. Після того, як будуть перенесені записи справи і створена резервна копія, інформація видаляється і файл стає готовим для наступного перенесення з файлів журналів. Файл з макроскопічним обстеженням включає в себе інформацію з лога, результати, основані на візуальному обстеженні матеріалу патологом, будь-які довідкові величини із стандартизованої інформації про справу (якщо є), які дозволяють швидко вводити всю повторювану інформацію зі схожих попередніх справ, перед- і післяопераційний діагноз терапевта(ів), що бере участь, стандартизовані коди тканин і захворювань (якщо є), ім'я патолога, який обстежував. Файл з денними обстеженнями включає в себе всі дані, перенесені з файла з макроскопічним обстеженням, плюс результати мікроскопічного обстеження патологом зрізів, діагностику по справі, дані рецензування по гарантіях якості і заповнену інформацію по справі. Використовуються різні типи полів для того, щоб забезпечити акуратне і повне проведення обстеження пацієнта і прискорене введення даних. Ці типи включають в себе обов'язкові перевірки введення на наявність помилок, поля з обмеженим введенням даних, розраховувані поля і поля пошуку, як це описано в огляді нижче. Файл денного обстеження включає інформацію з журналу, результати макроскопічного обстеження, звіт про мікроскопічне обстеження зрізів патологом, діагностику справи патологом, обов'язкові перевірки введення на наявність помилок, поля з обмеженим введенням даних, розраховувані поля, поля пошуку і поля гарантій якості. Поля з обов'язковою перевіркою введення на наявність помилок вимагають, щоб в них була введена інформація раніше, ніж звіт по обстеженню буде збережений або переданий. Дані в цих полях є обов'язковими для правильної звітності за результатами обстежень і аналізу гарантій якості. Поля введення з обов'язковою перевіркою на наявність помилок в даному варіанті здійснення це: "std" - перенести інформацію по справі в стандартизований (standardized) файл справ - у або n; "and" - додаткова (addendum) справа - у або n; "cty" - тип цитологічної (cytology fluid type) рідини; "cs" - джерело цитологічної рідини (cytology fluid source); "#cs" - кількість цитологічних зрізів (cytology slides); "rev" - інформація по рецензії (review) патолога. Результати 12 UA 97803 C2 5 10 досліджень не будуть перенесені без входжень цих полів, "arev" - статус рецензії, вказаної вище (review above); "origin of specimen" (походження зразка) - медична галузь лікаря, що бере участь; "sentln" - присутність сигнальних лімфатичних вузлів в зразку - у або n; "report date" (дата звіту) дата виконання досліджень патологом (результати не будуть передані, якщо це поле не заповнене). "Hold" (затримати) - справа завершена - у або n (дослідження не повинно утримуватися, щоб відбулася передача); і "Rhold" - обґрунтування для затримки (reason for hold) (обстеження не буде перенесене, якщо це поле не заповнене, а якщо справа була в статусі "hold" більше трьох днів, то вона повинна мати значення, відмінне від "no hold"). У поля з обмеженим введенням можна вводити тільки ті дані, які показуються на екрані в момент вибору цих полів. Таблиця полів з обмеженим введенням і асоційованими варіантами для кожного поля. Значення в цій таблиці наведені для прикладу і є ілюстративними. 13 UA 97803 C2 14 UA 97803 C2 15 UA 97803 C2 16 UA 97803 C2 17 UA 97803 C2 5 Обчислювані поля мають значення, основані на значеннях з інших полів в тому ж файлі або значеннях з інших пов'язаних файлів. Після того, як інформація введена автоматично, заборонене ручне введення даних. Для поля можуть бути визначені рівняння за умовчанням, 18 UA 97803 C2 5 10 15 20 25 30 35 40 45 50 55 60 але це тільки пропоновані величини. Величина вставляється автоматично, тільки якщо в полі в даний момент немає даних, За необхідності величина може бути виправлена оператором. Прикладами розраховуваних полів і відповідних рівнянь за умовчанням є наступні: аа. mamact - поле з дією по грудях if [mammat] = "01" or [mammat] = "03" then "01" else "00" bb. type - джерело справи пацієнта, тобто S, Ρ, Β або G і визначається з початкового запису у відповідному файлі журналу left([case nо], 1) сс. pmtcase - номер справи без номера сторінки left([case nо], 12) dd. pcode - код лікаря, використовуваний для статистики звітності по гарантіях якості filelookup([physican. physician], [physican. pcode], [physicianl]) ее. pcode2 - код лікаря, використовуваний для статистики звітності по гарантіях якості file lookup([physican. physician], fphysican. pcode], [physician2]) ff. о - тип терапевта, що бере участь (хірургія, акушерство-гінекологія, ендоскопія і т. д.) filelookup([physican.physician], [physican.o], [physicianl]) gg. In - визначає, належить справа до прояснення лімфи, чи ні select([gross] ! "clearing", "In") else "nl" hh. lnp - потрібна чи ні сторінка прояснення сигнального лімфатичного вузла select([ln] ! "In", "Lymph Node Clearing Page Required") else "No LN Page Required" ii. dc - передана чи ні справа для видалення кальцифікатів select([gross] ! "submitted for decal", "dc") else "nd" jj. dcp - потрібна чи ні сторінка по декальцифікації select([dc] ! "dc", "Decal Page Required") else "No Decal Page Required" kk, sn - справа з сигнальним лімфатичним вузлом, чи ні select([specimen 1] "senti", "sn")([specimen2] "senti", "sn")([specimen3] "senti", "sn")([specimen4] ! "senti", "sn")([specimen5] "senti", "sn ')(lspecimen6] "senti", "sn") else "ns" ll. snp - потрібна чи ні сторінка по сигнальному лімфатичному вузлу select([sn] = "sn", "Sentinel Lymph Node Page Required") else "No Sentinel Page Required" mm. md - ініціали патолога select ([pathologist] = "M. Rundell,", "MR") ([pathologist] = "E. Yang,", "EY")([pathologist] = "J. Smith,", "JS")([pathologist] = "L. Jones,", "LJ") else blank nn. clinact - повідомляє патолога про можливу відмінність між обстеженням на патологію і клінічним представленням if ([prematch] = "03" or [prematch] = "04" or [prematch] = "05" or [prematch] = "08") then"* Note: Path Ox may not coincide with clinical impression, clinical correlation is suggested." else blank oo. specact - представленої тканини недостатньо для проведення діагностики if ([sc] = "04" or [sc] = "05" or [sc] = "07") then "* Note: No specific pathologic diagnosis can be made. Additional tissue is required if clinically indicated." else if [sc] = "09" then "* Note: Tissue adequate but no specific pathologic diagnosis can be made." else if [sc] = "02" then "* Note: This specimen was improperly fixed when received." else blank pp. hcase no - номер справи, якщо запитане спеціальне фарбування select([hr] =· "у", [prntcase]) else null qq. hreq date - дата запиту спеціального фарбування select([hr] = "у", today) else blank rr. htime - час запиту спеціального фарбування select([hr] = "у", time) else blank ss. rholdreq - причина, через яку справа затримується if [hr] = "у" then [rhold] else null Поля пошуку містять значення, основані на величинах, одержаних з інших полів в пов'язаних файлах. Можливий миттєвий пошук даних в сотнях і тисячах записів в пов'язаних файлах. Пошук може бути ручним, за допомогою введення найближчого придатного символу і вибору потрібного запису, або автоматичним, основаним на повному збігу значень полів в пов'язаних файлах і введенні необхідної інформації у відповідне поле без втручання оператора. Результати ручного пошуку можуть бути перезаписані, в той час як результати автоматичного пошуку можуть бути змінені тільки у випадку, якщо пошук є рівнянням за умовчанням, але не обчислюваним полем. аа. sdl - поле пошуку, основане на зразках в стандартизованому файлі справ для обстеження патологом. Повертається ідентифікатор, який складається з ініціалів лікаря і 19 UA 97803 C2 5 10 15 20 25 30 35 40 номера справи. Ідентифікатор справи використовується як зв'язок для автоматизованого поміщення інших полів зі стандартизованого файла патолога в поточну справу. Величини пошуку вставляються у відповідні поля і можуть бути за необхідності перезаписані патологом, який виконує обстеження. Поля пошуку, пов'язані з величиною sdl, наступні: gross (короткий виклад фізичного і мікроскопічного дослідження патолога); diagnosis (одержані патологом дані); tissue cdl; slide code; aslide; prematch; sc; cs; cry; cytomtch; t1-t5 (коди тканини, які представляють області зразка тканини для справи); d01-d05 (коди захворювань, відповідні зразкам тканин); tumor code; tnm (метастаз пухлинного вузла, який показує розмір і природу пухлини лімфовузла); qacomment (коментарі патолога для контролю якості справи, якщо є); sec; frozen; afxmatch; mam; premam; ms; mammat і mamact (дія, яку необхідно виконати, якщо вище є відмінність). bb. t1-t5 - пошук по імені основного файла з областями тканин. Повертається код з двох цифр, який представляє область. сс. d01-d05 - пошук по імені основного файла із захворюваннями. Повертається код з п'яти цифр, який представляє тип захворювання. dd. abname1-5 - пошук по імені пацієнта в файлі з історичним архівом. Повертається номер справи будь-якого попереднього дослідження. ее. physician - пошук в основному файлі терапевта. Повертається ім'я терапевта, що бере участь. ее. physician2 - пошук в основному файлі терапевта. Повертається ім'я терапевта, що бере участь. gg. ss1-12 - пошук в основному файлі типів фарбування. Повертається код необхідного коду фарбування. Поля гарантій якості - це поля, з яких дані збираються в історичних файлах для побудови трендів і статистичного аналізу, формування звітів про кореляцію результатів досліджень по департаменту і походженню справи. Поля гарантій якості включають в себе tissue cdl; slide code; aslide; prematch; mam; premam; rns; mammat; mamact (індикація випадків, переданих в комітет, якщо є різниця між діагнозами доктора і патолога); bmark (кількість міток грудної клітки в зразку); cytomtch; acyto (передбачувана дія, залежно від кореляції між цитологічним зрізом і зразком); sc; outside consultant; aout (передбачувана патологом дія як результат зовнішньої консультації, якщо така використовувалася); frozen; afxmatch; frozen code (кількість заморожених зразків); frnin (час в хвилинах проведення дослідження замороженого зразка); rfd (причина затримки >20 хвилин при дослідженні замороженого зразка); afd (передбачувана патологом дія для затримок більше 20 хвилин); frnm (міра відмінності діагнозу замороженого зразка і остаточного діагнозу); pathologist; sec; page (ознака останньої сторінки дослідження, яка включає статистику контролю якості); tumor code (стандартизований код новоутворення, якщо є); tnm (метастаз пухлинного вузла); clinact (передбачуване повідомлення лікарю, що обстежує, про можливу відмінність з клінічним враженням, надруковане в денних звітах); і specact (індикатор недостатньої придатності зразка для діагнозу, надрукований в денних звітах). Денні звіти по гарантіях якості показані в наступній таблиці. 20 UA 97803 C2 5 10 Місячний файл досліджень включає всі дані, перенесені з денного файла обстежень по завершенні справ. Річний файл досліджень включає всі дані, передані з денного файла обстежень по завершенні справ. Файл обстежень з історичним архівом включає всі дані, передані з денного файла обстежень по завершенні справ за наступними виключеннями: інформація про зразок, одержані патологом дані фізичного і мікроскопічного обстеження, інформація по запиту на спеціальне фарбування і будь-які коментарі патолога по гарантіях якості. Денні звіти покривають завершені справи, що переносяться на щоденній основі в місячні, річні файли і файли з історичними архівами. 21 UA 97803 C2 Місячні звіти по гарантіях якості показані в наступній таблиці. 22 UA 97803 C2 5 Аналогічні звіти можуть генеруватися за рік і/або за будь-який вказаний проміжок часу. У різних варіантах здійснення денні і місячні звіти можуть бути однаковими за формою, 23 UA 97803 C2 5 10 15 20 25 30 35 40 45 50 55 60 розрізнюючись тільки часовим діапазоном. Ці денні звіти можуть дозволити патологу за необхідності вжити швидкі коректуючі заходи до процедур обстеження і до звітності, а також прискорити процес підготовки необхідних місячних звітів. Місячні звіти можуть бути автоматично відсортовані і розпечатані департаментами лікарні і зовнішніми лікарями або медичними групами, дозволяючи тим самим швидке і просте поширення звітів. Будь-які справи, визначені як «стандарти» або шаблони для майбутніх звітів по дослідженнях в схожих справах, передаються відповідному патологу і в файли стандартів. Справи, в яких є проблемні зрізи, визначаються і передаються в гістологічний файл журналу для подальшого перегляду і перевірки. Справи з відмінностями між діагнозом терапевта(ів), який обстежував, і клінічним враженням передаються в файл журналу попереднього зіставлення для подальшого перегляду. Наступні типові внутрішні звіти на доповнення до персональних звітів про дослідження, згадані раніше, можуть бути надруковані для внутрішньої перевірки даних в звітах і для проведення додаткових дослідницьких і діагностичних процедур. Наступні назви екранних представлень є лише зразковими і ілюстративними. 1. Денний список виконаних справ. Екранне представлення називається "dailycasetr". 2. Денний звіт цитологічних препаратів по патологу. Кількість зрізів, досліджених патологом, легко перевірити, щоб пересвідчитися, що завантаження денними справами не перевищує рекомендованих значень. Екранне представлення називається «cytslide#». 3. Огляд справ з відмінностями між лікарями, які обстежували, перед- і післяопераційним діагнозом і клінічним враженням патолога. Екранне представлення називається «prematchlog». 4. Огляд затриманих справ. Екранне представлення називається «dailyholdaction». 5. Огляд всіх справ по сигнальних лімфатичних вузлах, які чекають подальшого аналізу і контролю статусу. Екранне представлення називається «sentlnd». 6. Звіт по всіх справах про захворювання грудей, посланих в ER/PR. Екранне представлення називається «breasterpr». 7. Звіт по всіх зразках грудних імплантатів, затриманий на невизначений час. Екранне представлення називається «Breastim». 8. Звіт для аналізу всіх справ про захворювання грудей з незлоякісною пухлиною. Екранне представлення називається «breastn». 9. Звіт для аналізу всіх справ про захворювання передміхурової залози з незлоякісною пухлиною. Екранне представлення називається «prostraten». 10. Звіт по всіх справах із замороженими зразками, які перевищують 20-хвилинний поріг аналізу або мають більше 4 заморожених зразків. Екранне представлення називається «frozl». 11. Звіт по всіх вибраних зрізах з проблемами. Екранне представлення називається «daily slide pro». 12. Звіт по всіх ще утримуваних справах, відсортований патологом. Екранне представлення називається «dailyholdmd». Звіт можна запускати на одній сторінці або на множині сторінок. Остання сторінка, якою б вона не була, призначена для показників гарантій якості для даної справи. Звітність по гарантіях якості включає в себе останню сторінку кожної справи, яка передається на щомісячній основі у вигляді окремого запису в базу даних звітності по гарантіях якості. У деяких випадках може бути декілька звітів. У випадках з декількома звітами справа може мати декілька звітів по якості. Хоч способи і системи різних варіантів здійснення даного винаходу були описані в сполученні із здійсненням генерації звіту по патології, можуть бути розглянуті і інші варіанти здійснення. Способи і системи можуть бути використані будь-яким користувачем, який заповнює форми і який міг би використовувати методику «стенографії». Наприклад, патрульна поліція могла б використовувати портативний пристрій введення для генерації штрафів або звітів про розслідування. Обчислювальна машина може також автоматично або по команді проводити фонову перевірку водійський прав або реєстраційних номерів автомашин. Можуть автоматично відстежуватися метрики якості, такі як час, необхідний для проведення кожного дослідження, і число досліджень, виконаних за звітний період. Обмін даними між дослідниками може допомогти підвищити ефективність звітності по проведених дослідженнях. 24 UA 97803 C2 5 У іншому прикладі менеджери відділу контрактів можуть починати шаблон контракту зі стандартною мовою. Після введення користувачем визначених значень в передбачені для цього місця, обчислювальна машина може додати додаткові умови на основі введених значень. Можуть автоматично відстежуватися метрики якості, такі як час, необхідний для переговорів за кожним контрактом, і число ревізій контракту. Попереднє розкриття і опис винаходу є ілюстративними і пояснювальними, але в осяжних межах галузь застосування даного винаходу визначена прикладеною формулою винаходу. ФОРМУЛА ВИНАХОДУ 10 15 20 25 30 35 40 45 50 55 60 1. Система для генерації звіту, що містить: базу даних; пристрій голосового введення, сконфігурований приймати дані і одну або більше команд; обчислювальну машину, підключену до пристрою голосового введення щонайменше визначений період часу, причому обчислювальна машина приймає дані і одну або більше команд від пристрою голосового введення, і причому обчислювальна машина сконфігурована здійснювати доступ до бази даних і зберігати одну або більше команд у базі даних; шаблон звіту, що містить множину полів, кожне з яких відповідає одному або більше розташуванням у базі даних; і обчислювальна машина додатково сконфігурована генерувати звіт на основі шаблону, причому звіт містить: щонайменше підмножину даних, асоційованих з одним або більше полями шаблону; величини, витягнуті з бази даних, у відповідь на щонайменше одну з однієї або більше команд, асоційованих з одним або більше полями шаблону; і одне або більше полів індикаторів контролю якості, визначених обчислювальною машиною і доданих до шаблону звіту на основі шаблону або полів, заповнених у шаблоні. 2. Система для генерації звіту за п. 1, у якій обчислювальна машина додатково сконфігурована зберігати дані в одному або більше вибраних розташуваннях у базі даних у відповідь на одну або більше команд. 3. Система для генерації звіту за п. 1, у якій обчислювальна машина додатково сконфігурована зберігати дані в одному або більше вибраних розташуваннях у базі даних на основі внутрішньої конфігурації. 4. Система для генерації звіту за п. 1, у якій поля індикаторів величин контролю якості містять поля з обов'язковою перевіркою помилок. 5. Система для генерації звіту за п. 1, у якій поля індикаторів контролю якості містять індикатор придатності патологічної вибірки для діагнозу. 6. Система для генерації звіту за п. 1, у якій поля індикаторів контролю якості містять індикатор ступеня відмінності між патологічними зразками і остаточним діагнозом. 7. Система для генерації звіту за п. 1, у якій поля індикаторів контролю якості містять порівняння цитологічного зрізу зі зрізом тканини. 8. Спосіб створення звіту, причому спосіб включає етапи, на яких: використовують пристрій голосового введення для введення приміток про одне або більше спостережень, причому примітки включають в себе дані і одну або більше команд на те, як представляти одне або більше спостережень у звіті; обчислювальним пристроєм приймають примітки від пристрою голосового введення і зберігають примітки в базі даних; обчислювальним пристроєм виділяють одну або більше команд із приміток і розташовують примітки про одне або більше спостережень у звіті на основі однієї або більше команд згідно із шаблоном звіту; обчислювальним пристроєм додають у шаблон звіту одне або більше полів індикаторів контролю якості на основі шаблону або полів, заповнених у шаблоні; і генерують звіт. 9. Спосіб за п. 8, у якому додатково: додають збережуваний матеріал у звіт у відповідь на запит упримітках. 10. Спосіб за п. 8, у якому додатково: додають збережуваний матеріал до звіту без запиту в примітках на додавання збереженого матеріалу. 11. Спосіб за п. 8, у якому додатково: виконують одне або більше спостережень для поміщення у звіт. 25 UA 97803 C2 5 10 15 20 25 30 12. Спосіб за п. 8, у якому додатково: обчислювальним пристроєм одержують одне або більше входжень в одній або більше баз даних у відповідь на одну або більше команд, причому одне або більше входжень додається у звіт. 13. Спосіб за п. 8, у якому поля індикаторів контролю якості містять поля з обов'язковою перевіркою помилок. 14. Спосіб за п. 8, у якому поля індикаторів контролю якості містять індикатор придатності патологічної вибірки для діагнозу. 15. Спосіб за п. 8, у якому поля індикаторів контролю якості містять індикатор ступеня відмінності між патологічними зразками і остаточним діагнозом. 16. Спосіб за п. 8, у якому поля індикаторів контролю якості містять порівняння цитологічного зрізу зі зрізом тканини. 17. Спосіб генерації звітів, що включає етапи, на яких: приймають ідентифікатор шаблону звіту від пристрою голосового введення; витягають шаблон звіту, що відповідає ідентифікатору шаблону звіту, з першої бази даних; приймають першу команду від пристрою голосового введення, причому перша команда містить інструкції для навігації до першого поля входження даних шаблону звіту; вводять дані в перше поле входження даних; приймають другу команду від пристрою голосового введення, причому друга команда містить перший код; витягають перший запис, що відповідає першому коду, із другої бази даних, причому перший запис містить команду для вставки полів індикаторів контролю якості із другої бази даних у шаблон звіту на основі шаблону звіту або полів, заповнених у шаблоні звіту; виконують команду для вставки полів індикаторів контролю якості в шаблон звіту; генерують звіт по шаблону звіту; і автоматично передають звіт попередньо визначеному одержувачеві. 18. Спосіб за п. 17, у якому щонайменше одне з полів індикаторів контролю якості повинно бути заповнене перед виконанням етапу, на якому генерують звіт по шаблону звіту. 19. Спосіб за п. 17, у якому щонайменше одне з полів індикаторів контролю якості містить обов'язкові поля перевірки помилок. 26 UA 97803 C2 27 UA 97803 C2 28