Бизнес-анализ -Сангвис – ИТ Пеликан Сдача крови

22.05.2011 at 14:41 Оставьте комментарий

Часть 4 подсистема Продукция Операционная

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

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

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

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

То, что решится технический вопрос, сомнений не вызывало. А вот как будет с технологией?

Попробую поподробнее рассказать — что там происходит с точки зрения наших проблем.

Итак, донор входит в операционную. В руках у него направление на кроводачу(до автоматизации — это была его донорская карта), которое он предъявляет регистратору операционной. Мы зафиксировали эту «роль» в технологическом процессе, так как именно на это рабочее место поставили компьютер и соответствующий АРМ.

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

Далее – самый сложный момент:

  • донору ставится в соответствие пакет для забора крови (или плазмы) – пока еще пустой, но имеющий свои параметры (правда не уникальные, а относящиеся к партии), которые обязательно должны быть зафиксированы
  • появляется идентификатор «номер кроводачи», сконструированный по тем или иным правилам (он может содержать внутри себя номер донора или нет). До автоматизации в журнале кроводачам присваивались порядковые номера внутри календарной даты – то есть идентификатор содержал 2 части: дата и номер внутри даты, и не содержал никаких данных о доноре. Связь осуществлялась путем записи в одну строку в журнале.
  • донору в руки вручались 2 (а иногда раньше и 3) пробирки для взятия образцов крови на анализ сразу после кроводачи – то есть из вены.

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

Для этого придумывались всяческие ухищрения – бирки, браслеты, дополнительные марки-метки и т.д (вот тут – на каждой СПК – кто во что горазд) – чтобы это соответствие реально обеспечить.

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

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

Достаточно сказать, что когда мне довелось побывать в центрах крови за рубежом (с 1994г. по 1998г), бросился в глаза такой момент: сотрудники центра крови, работающие с донорами, включая персонал операционной, одеты в некую нейтральную форму, но уж точно не белые халаты. Я сразу спросила – почему (ведь у нас весь персонал был одет в белые халаты, включая бухгалтеров, кладовщиков и механиков). Объяснили – доноры, это не больные, а наоборот – очень здоровые люди. И там, где они есть, больничная обстановка должна быть исключена. Людям должно быть комфортно.

А вот в тех подразделениях, где идет работа с уже полученной от донора кровью и пробирками, там белизна (цвет может быть другой, но требования к чистоте повышенные), перчатки, маски и т.д. Там уже производство, с особыми, специфическими требованиями обеспечения различных аспектов безопасности.

Придя в операционную со своей автоматизацией, мы использовали уже принятый и согласованный подход: на первом шаге ничего по-возможности не менять в технологии, не нарушать привычный ход работы персонала, но компьютер в их работу встроить. В случае с операционной, первая версия программы была наверное даже не пилотным проектом, а элементом обследования и бизнес-анализа.

И хотя номер кроводачи теперь Система стала присваивать автоматически и ставить его в соответствие коду донора, но структуру этого номера на данном этапе мы не меняли.

Тем не менее, что-то все равно в работе персонала изменилось. Сам факт, что теперь регистратор операционной по данным документа «Направление на крововдачу» ищет донора в оперативной БД, а не записывает в свой, совершенно локальный журнал, уже позволяет:

  1.  Ужесточить контроль прихода доноров в операцинную – сдать кровь может только тот, кто найден в оперативной БД, а следовательно прошел контроль по картотекам и осмотр врача и допущен к кроводаче. Нельзя сказать, что при ручной технологии каждый день были доноры, которые могли сдать кровь в обход осмотра врача. Но отлавливать таких иногда приходилось
  2. Снизить трудоемкость и сократить количество ошибок «писанины в журнале». Ввод всех данных о доноре в системе уже одноразовый – только в донорском отделе.
  3. Усилить контроль за полнотой оформления документов при направлении на кроводачу – некоторые количественные и качественные показатели сразу были поставлены на программный контроль, сообщения об ошибках выдавались сразу и в операционной, и у администратора. А вот это уже не очень понравилось докторам, по крайней мере некоторым. Про врачебный почерк все знают – что прочитать ничего нельзя… Ну и полнота данных в карточках оставляла иногда желать лучшего. Проверяющие всегда могли что-то найти. Но это же потом… А теперь –прямо в процессе работы.

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

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

С основной частью направления, где также отмечался факт кроводачи, донор уходит в кассу, где получает деньги и справки.

Вот примерно так выглядела наша информационная технология – ИТ Пеликан, когда мы проводили в 1993г свой второй семинар и ее увидел господин Максимовский Александр Степанович.

Фото Игорь Подгорный 2009г. Акция  Доноры — детям…

Реклама

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 такие блоггеры, как: