Бизнес-анализ Сангвис ИТ Пеликан Работа с донорами

12.03.2011 at 09:30 Оставьте комментарий

Часть 3 Подсистема Доноры — 3

Блок Картотека (банк данных) доноров

Это центральная часть и БД и всей ИТ Пеликан.

При формировании структуры Картотеки доноров было принято решение не делать больших различий между кадровыми донорами (у которых были большие карты) и всеми остальными. Жизнь показала, что это решение правильное, и хотя в системе имеется возможность относить доноров к разным категориям, с точки зрения содержательной и нормативной – это не простая задачка (на языке системы – правильно поставить код вида донора). В системе нет принципиальных отличий между кадровыми донорами и теми, кто сдают кровь эпизодически – структура базы позволяет для любого донора ввести (а следовательно потом и найти) любую – вдруг потребовавшуюся — информацию.

Первый вопрос, который решался при создании БД Доноры – это идентификация.
Вопрос сложный. На тот момент как раз начали создаваться различные системы, использующие, как теперь принято говорить, «персональные данные» — ЗАГСы, МВД (там какие-то БД уже были конечно, но к ним попробуй достучись), пенсионный фонд, налоговая служба – эти позже нас. И каждая система имеет свою идентификацию – так ведь и до сих пор. Вот только в 2010г начали говорить и писать об универсальной электронной карте, но что еще из этого будет. Все последующие за 1990г-м я следила за работми НИИ Восход по созданию ПИН – так у них называлось – персонального идентификационного номера. Сколько же денег туда было закачено! Но в целом по стране так и на сегодня пока ничего нет.

Мы, поняв, что проблема сложная и хорошее решение потребует значительных усилий и времени, не стали на ней зацикливаться и приняли решение, которое тогда считали временным, чтобы просто пойти дальше в своей системе. Понимая, что решение это «плохое» и очень многих проблем не решает.
Мы очень недалеко ушли от простой нумерации всех доноров подряд – нумеровали их внутри года регистрации на СПК. Это давало возможность хоть как-то использовать идентификатор для группировки, а опытные работники службы крови по году регистрации как-то умели сразу много выводов делать.
Этот номер использовался для идентификации именно программной системой. Для врачей и регистраторов механизм идентификации личности был разработан довольно сложный – оказалось, что в миллионном городе (даже в такой узкой подгруппе людей как доноры), много полных однофамильцев – то есть могут совпасть и фамилия, и имя и отчество. Не является надежным идентификатором номер паспорта (а тогда еще была серия, записываемая римскими цифрами – ее часто вводили с ошибками). Поэтому для специалиста на экран для идентификации выводится полностью: ФИО, полная дата рождения и номер паспорта. И только при полном совпадении всего, продолжается работа с донором.
Для поиска – можно  искать и по фамилии (выдается список), и по номеру паспорта, и по идентификатору ID.

Но вот либо донор найден, либо установлено, что его пока в БД нет.
Если найден — врачу доступна вся предшествующая информация о доноре: количество кроводач и количество сданной крови (плазмы), характеристики крови (группа крови и резус-принадлежность, эритроцитарные антигены, а так же выявленные антирезусные антитела и антитела анти А и анти В и др.), анализы от предшествующей кроводачи и анализы в динамике кроводач (на носительство инфекций, клинические и биохимические исследования), наличие выявленных при скрининге антибактериальных и антивирусных антител, содержание антител, являющихся результатом иммунизации, данные о прививках, данные осмотров и результаты обследований, полученные из внешних медицинских учреждений (например, рентгеноскопии и др.).
Если нет – вводятся в момент оформления на кроводачу паспортные данные, адрес – все что положено по инструкции, а также решение относительно предстоящей кроводачи – что будет сдаваться, если кровь – то сколько. Система присваивает идентификатор ID.
Именно в этот момент формируется запись в оперативном файле, остальные операции производственного процесса, отражаемые в информационной системе, с файлом «Картотека доноров» не работают. Зато в оперативном файле запись длинная – предусмотрено все, что только может быть для одной кроводачи. Но записей – не много – несколько сотен.

Заполнение записи в оперативном файле сначала осуществляется по мере продвижения донора: регистарация, осмотр врача, потом лаборатория первичной диагностики. По инструкции перед кроводачей у донора необходимо проверить уровень гемоглобина (защита здоровья донора), и если донор первичный – определить предварительно группу крови (защита реципиента – группа крови определяется дважды – потом уже после кроводачи из пробирки).

На первом этапе – когда мало еще было компьютеров, данные об этих анализах вводились в кабинете врача, куда донор возвращался с результатами, записанными на бумажном бланке.

Потом был написан небольшой АРМ, и врач- лаборант, легко находя запись о доноре (она извлекается из оперативного файла), вводит свои данные сам. Теперь донору не нужно возвращаться в кабинет врача,  лишь в случае низкого гемоглобина лаборант предупреждает донора о необходимости снова пройти врача для принятия окончательного решения о возможности кроводачи. Причем, если донор этого не сделает, то его низкий гемоглобин высветится «красным окошком» на следующем этапе – в операционной. Но это уже позже – не в 1990г., а  тогда ИТ заканчивалась в Донорском отделе.

Для того, чтобы все это красиво работало, было решено две  задачи:
1. Структуризация БД. Кроме собственно картотеки доноров, содержащей лишь основную, паспортную информацию о доноре, в БД данных «Доноры»  предусмотрено еще несколько файлов, позволяющих хранить данные о разных аспектах работы с донорами. Для примера:  в файле «Кроводачи» на каждую запись в картотеке доноров формировалось столько записей, сколько раз донор сдавал кровь. Эти записи одного типа, и легко обрабатываются при поиске и анализе (не смотря на это, с целью ускорения именно аналитических работ и врача на приеме, и специалистов по работе с донорами, в картотеке хранились итоговые данные по количеству кроводач и объемам сданной крови и плазмы – техника у нас была слабая тогда, время вывода данных приходилось экономить). А в другом файле хранились данные об обследованиях донора, не связанных с кроводачами – были и такие (в инструкции называлось – справка от терапевта, данные флюрографии и т.д). А некоторые доноры были не просто кадровые, а еще и имуннизированные — их в службе крови прививали от определенных инфекций (иммунизировали) – стобняка, клещевого энцефалита и др, с целью выработки антител к этим инфекциям. Из плазмы именно этих доноров потом изготавливаются специфические иммуноглобулины – противоинфекционные препараты. Для таких доноров процесс иммунизции и дополнительных анализов с этим связанных,  также фиксировался в отдельном файле. Разнесение данных позволило эффективно использовать возможности техники и СУБД того времени.

2. Вторая задача – организационная. Создание картотеки доноров в период внедрения системы. Если карточки отведенных было доверено вводить многим сотрудникам СПК, то донорские карты – это и ответственнее, и гораздо сложнее. Оценив трудоемкость этой работы, Нижечик Ю.С. принял компромиссное решение. Ввели все карты кадровых доноров в паспортной части, а также данные о последней кроводаче, предшествовавшей моменту внедрения, и общие итоги по количеству кроводач и объемам сданной крови и плазмы. Работу с некадровыми донорами начали как с чистого листа – хранившиеся маленькие карты как правило, не вводили. Довольно долго хранили под руками бумажные архивы, к которым обращались в случае необходимости, и еще очень долго (тогда так казалось) работали и с ИТ системой, и с бумажными картами.
Но пришло время – и было снова принято организационное решение – Сангвис начал работать без бумажных карт. Но об этом чуть позже.

А пока – о той реорганизации, которая уже упоминалась – отказе от регистратуры.
В тот момент, когда первоначальная загрузка данных в картотеки – и отводов и доноров – была закончена, трудоемкость работы в донорском отделе резко снизилась.
А тут как раз мы семинар проводили, народу свои первые успехи показывали. И, как я уже рассказывала, идею нам подкинули на семинаре, но она нам пришлась очень по вкусу.
Сели мы вместе с докторами, поговорили. Не надо думать, что врачи донорского отдела приняли идею сразу. Конечно, вскрики – «вот нас уже и до регистраторов опускают!» — были.
Но уж очень было соблазнительно полностью изменить технологию работы, сделать следующий шаг, очень немаленький, перейти от «подстрочника», который мы умышленно делали, к принципиально новому решению.
И довольно быстро это решение было реализовано. Что регистраторов может быть меньше, это было очевидно и их сразу начали переводить в другие службы.
Затем было оформлено организационно (в виде инструкции –регламента)-отделение функций «ведение картотек отводов» от работы собственно донорского отдела по обследованию доноров.

Для доноров количество очередей и кабинетов уменьшилось – теперь он входит только в кабинет врача и в лабораторию. Если на приеме кадровый донор (а в дальнейшем достаточно было чтобы он был просто «повторный» – вид донорства, которого до автоматизации не было, но система находит донора, если он был и год, и два назад, и вообще – когда- либо), то вся дополнительная работа врача сводится к вводу фамилии – система и по картотекам проверяет, и донора находит, и адрес выводит вместе со всем остальным.
Если донор первичный, то работы конечно побольше – контроль по картотекам – это легко и быстро, но если донор допущен к кроводаче – данные надо вводить.
Некоторые врачи восприняли эту работу даже с энтузиазмом – они быстро оценили и общий эффект для Донорского отдела, и аналитические возможности на приеме.
Другие были очень недовольны, и для таких докторов (а также для случаев, когда в какой-то день поток доноров оказался существенно больше среднего) был предложен вариант, когда врач работает с помощником (и тот осуществляет ввод данных). Благодаря сетевой реализации системы, она легко адаптируется к величине донорского потока- одновременно могут принимать доноров как 1-2, так и 4-5 и более врачей.

На фото: демонстрация работы врача донорского отдела в 1997г. За компьютером доктор Упоров В.И. — наш консультант и помощник во внедрении. У него на приеме донор. Мы (Нижечик и я) демонстрируем систему гостям из ГНЦ (гематологического научного центра) — его директору академику Воробьву А.И. и зам. директора профессору Городецкому В.М. (он виден за спиной доктора Упорова).  В демонстрации принимает участие зав.донорским отделом Власюк И.К.

Реклама

Entry filed under: Мемуары Сангвис. Tags: , , .

Бизнес-анализ Сангвис ИТ Пеликан Картотека отводов Проект Закона об образовании и театр с балетом

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

Trackback this post  |  Subscribe to the comments via RSS Feed


Подписка на новости сайта

Подпишитесь на новости сайта (RSS)

RSS

Архивы

Рубрики

Главные книги аналитика

Современные методы описания функциональных требований к системам | Алистер Коберн
 Разработка требований к программному обеспечению |Карл И. Вигерс, Джой Битти

Требования для программного обеспечения: рекомендации по сбору и документированию |Илья Корнипаев
Анализ требований к автоматизированным информационным системам | Юрий Маглинец
Пользовательские истории. Гибкая разработка программного обеспечения |Майк Кон


%d такие блоггеры, как: