Требования к разработчику и пользователю диагностического инструментария
Вопросы к экзамену по дисциплине «Психодиагностика »
(на данной страничке прикреплен файл с программой по подготовке к экзамену)
1. Развитие зарубежной психодиагностики XIX – XX веках.
2. Основные этапы становления психодиагностической науки в России.
3. Предмет психодиагностики как науки и практической деятельности.
4. Подходы к пониманию психологической диагностики (распознаванию, измерению и психодиагностическому прогнозу)
5. Задачи, принципы и ситуации психологической диагностики
6. Применение психодиагностических методов в системе образования. Диагностика психологической готовности к обучению в школе.
7. Применение психодиагностических процедур в медицине
8. Психодиагностика на службе профессионально-трудовой деятельности
9. Использование психодиагностических средств в судебно-психологической экспертизе.
10. Общая характеристика перспективных направлений развития психодиагностики.
11. Дифференциация категорий «метод» и «методика» в психологической науке. Возможности классификации психодиагностических методик.
12. Классификации психодиагностических методик.
13. Проективные методики: виды и общая характеристика.
14. Проблема проективного метода в психологии.
15. Психологический диагноз как процесс (возможные модели и схемы психодиагностического процесса)
16. Психологический диагноз как результат деятельности практического психолога.
17. Стандартизация теста. Этапы стандартизации. Кривая нормального распределения. Статистические нормы.
18. Стандартные показатели ( z -стандартный показатель, процентиль, станайн, стэн, социально-психологический норматив)
19. Адаптация теста. Алгоритм адаптации
20. Трудность и дискриминативность заданий теста. Психометрический парадокс
21. Надежность теста ее виды и процедуры проверки надежности.
22. Валидность теста , виды валидности.
23. Репрезентативность и внутренняя согласованность
24. Опросники структуры личности: типологический подход.
25. Виды опросников и их общая характеристика.
26. Общая характеристика стандартизированных опросников.
27. Диагностика психических состояний личности.
28. Диагностика динамических аспектов поведения и деятельности человека.
29. Психосемантические методы диагностики личности.
30. Диагностика межличностных отношений.
31. Общая характеристика тестологического направления в психодиагностике.
32. Общая характеристика теста как психодиагностической методики. Основные направления психологического тестирования.
33. Классификации психологических тестов. Общая характеристика объективных тестов.
34. Критериально-ориентированное тестирование.
35. Тесты достижений: характеристика, типология, область применения.
36. Общая характеристика тестов интеллекта и умственного развития. Коррекционные возможности психодиагностики умственного развития.
37. Диагностика когнитивной сферы.
38. Психодиагностические методики измерения ценностно-бытийной сферы личности.
39. Диагностика потребностно-мотивационной сферы личности.
40. Комьпютеризация психологической диагностики.
41. Возможности исследования специальных способностей.
42. Общая характеристика тестов креативности.
43. Основные требования к разработчику, распространителю и пользователю диагностического инструментария.
44. Этические нормы диагностического исследования.
КРИТЕРИИ ОЦЕНКИ ЗНАНИЙ СТУДЕНТОВ
ПО УЧЕБНОЙ ДИСЦИПЛИНЕ «Психодиагностика»
Выставляется студенту, продемонстрировавшему высокий уровень теоретических знаний и практических умений в области психологической диагностики. Студент владеет понятийным аппаратом изучаемой области, способен логично и последовательно представлять необходимую информацию, умеет самостоятельно и аргументировано осуществлять анализ и отбор психодиагностического инструментария. Студент адекватно применяет знания на практике при решении конкретных профессиональных задач педагога-психолога. Студент способен к постановке как этиологического, так и типологического психологического диагноза.
Выставляется студенту, продемонстрировавшему прочные знания материала, предусмотренного учебной программой, способность грамотно излагать информацию, умеет адекватно применять полученные знания на практике. Но при ответе на экзаменационный вопрос и в решении профессиональных проблемных ситуаций допускает некоторые неточности. Студент способен к постановке этиологического психологического диагноза.
Выставляется студенту, показавшему фрагментарный, схематичный уровень владения знаниями. Студент представляет недостаточно правильную формулировку основных понятий, нарушает логическую последовательность в ходе изложения программного материала, но при этом усвоил содержание основных разделов учебной программы дисциплины, необходимые для дальнейшего обучения и может применять полученные знания по образцу в стандартной ситуации. Студент способен к формулированию симптоматического диагноза.
Выставляется студенту, который не знает большей части основного содержания учебной программы дисциплины, допускает грубые ошибки в формулировках основных понятий дисциплины и не умеет использовать полученные знания при решении типовых практических задач или проблемных ситуаций.
Студент, получивший за работу в сестре оценку «неудовлетворительно», допускается к повторной пересдаче учебного материала.
Вопросы к экз по психодиагн_2012
Вопросы к экзамену по «Психодиагностике»
Место психодиагностики в системе психологической науки и практики. Основные области использования методов психодиагностики.
Подходы к пониманию основных задач психодиагностики: инструментальный, конструирующий, гностический, помогающий, практико-ориентированный, адаптационный, интегральный.
Этапы диагностического исследования и уровни психологического диагноза.
История психодиагностики. История, современное состояние и проблемы отечественной психодиагностики.
Общая характеристика диагностического исследования.
Сравнительный анализ тестологического и клинического направлений в психодиагностике и перспектив их сближения.
Естественно-научная и гуманитарная ориентация в методологии, методике и технике психодиагностического обследования. Номотетический и идеографический подходы.
Стандартизация условий и процедуры тестирования, обработки и анализа результатов
Надежность теста ее виды и процедуры проверки надежности.
Валидность теста, виды валидности: конструктная, критериальная, по содержанию.
Стандартизация диагностических критериев. Понятие статистической нормы и объективно заданного социально-психологического критерия.
Понятие о психологическом тесте.
Требования к тесту как к измерительному инструменту.
Классификация психодиагностических методик: стандартизированные и нестандартизированные методики.
Классификация психодиагностических методик: объективный, субъективный проективный подходы.
Общая характеристика объективных тестов.
Общая характеристика стандартизированных опросников.
Факторы, влияющие на достоверность результатов тестирования с помощью стандартизированных опросников.
Общая характеристика проективных методов. Проблема теоретического обоснования проективных методов.
Тесты интеллекта и общих способностей.
Тесты творческих способностей (креативности).
Тесты и батареи тестов специальных способностей: тесты сенсорных, моторных, технических, художественных способностей.
Тесты достижений: тесты достижений ориентированные на норму и на критерий; стандартизированные тесты достижений и «тесты учителя».
Личностные опросники: типологический и факторный подходы.
Опросники ценностей, мотивов, установок, интересов.
Диагностика межличностных отношений: социометрический метод в диагностике малых групп; опросники детско-родительских отношений; опросники диагностики супружеских отношений.
Диагностика психических состояний. Методические проблемы диагностики психических состояний. Физиологические и психологические методы диагностики психических состояний.
Требования к разработчику, распространителю, пользователю диагностического инструментария.
Этические нормы диагностического исследования. Этический кодекс психолога диагноста.
Иррациональные тенденции в работе психолога.
Взаимодействие разработчика и пользователя при эксплуатации информационной системы
Информационная система должна постоянно модифицироваться, и реализовывать изменения может только разработчик. Но пользователи должны как можно раньше ставить ему задачи и как можно точнее их описывать. Взаимодействие не сводится к формуле «скажите — сделаем», оно намного сложнее.
Обычно требуется от 4 недель до 3 месяцев, чтобы основная волна проблем, связанных с вводом медицинской информационной системы (МИС), схлынула. Однако на этапе внедрения выявляются не все недостатки. Если к функциям прибегают редко, ошибки могут скрываться годами.
Впрочем, устранение ошибок не единственный предмет взаимоотношений пользователя и разработчика. Постоянное развитие медицинской науки и организации лечебного дела отражается в работе с информацией. У органов управления здравоохранением и субъектов медицинского страхования также свои требования, довольно часто меняющиеся.
Причины запросов к разработчику и их значение
Запросы к разработчику возникают тогда, когда при работе с информацией пользователь испытывает неудобства или не может выполнить нужную операцию. Без этого не обходится ни одна МИС. Причина запросов — неизбежное несовершенство МИС. Сначала требуется исправление недоработок. Затем приходят запросы, вызванные переменами.
Все может начинаться с аморфных претензий: «нам не нравится», «сделайте удобнее», «добавьте такую-то возможность». И тут должны действовать строгие организационные правила: системный администратор, сам разработчик или руководитель ЛДП (заведующий отделением, главный врач, начмед) обязаны требовать от автора замечания описание проблемы и ее демонстрацию.
Запрос должен быть информативным, чтобы разработчик в деталях понял, что ему делать. Возможны и противоречивые запросы: одно и то же разные пользователи могут формулировать по-разному, не с каждым дополнением или изменением всегда согласятся. И не у каждого есть понимание, что предлагаемые изменения могут отразиться на многих функциях. Поэтому взаимодействие разработчика и пользователя требует организации, правил, распределения обязанностей и прав, инструментария. От обеих сторон необходимо понимание важности поддержки МИС разработчиком. Забота о техническом совершенстве системы — только самая простая часть задачи, причем не главная. Главная часть — поддержка на должном уровне содержания системы.
Организация запросов
Следует улучшать практическое воплощение принятых ранее решений. Например, бессмысленно повторять, что МИС должна соответствовать правилу «однократный ввод — многократное использование». Нужны конкретные формулировки об упрощении ввода данных в определенном месте электронного документа.
Удовлетворение запроса нередко требует нескольких итераций, детализирующих желательные изменения.
Однако если к проблемам можно приспособиться, например вернуться к ручке и бумаге, как правило, пользователь делает это. Чтобы пользователи не приспосабливались к неудобству, а требовали его устранить, надо обеспечить удобную обратную связь с разработчиком — организовать службу, которая должна регистрировать обращения, ранжировать их по видам (ошибки, вопросы, предложения и т. д.) и обеспечивать их передачу устранителям дефектов.
Обязательно на каждом рабочем месте должна быть доступна система, отвечающая за работу с обращениями. Она может быть как частью самой МИС, так и приложением. Подходящих приложений сегодня множество, в том числе простых в использовании и бесплатных.
Правильная организация работы канала информации предполагает следующее: информация должна быть снабжена датой ввода и поступать в оперативные сводки, пока пользователь не отметит удовлетворенность результатом. Адресатом запросов должен быть системный администратор, проверяющий обоснованность запроса (возможно, проблема заключалась в неверных действиях) и при необходимости передающий его разработчику вместе с нужными сведениями.
Следует утвердить формат предоставления информации.
Виды и формы запросов
Одни проблемы работы в МИС требуют немедленного решения, с другими можно повременить. Одни могут быть устранены быстро, другие требуют усилий. Одни являются результатом недоработок, другие — следствием новых требований, третьи диктуются индивидуальной особенностью. Поэтому для взаимодействия пользователей с разработчиком важно разделение запросов по форме предоставления. Пользователю должны быть заданы правила, за соблюдением которых обязан следить системный администратор.
Об аварийных завершениях и зависаниях программы
При зависании программы системный администратор должен позаботиться о точности описания предварительных действий, поскольку разработчику требуется повторить ситуацию.
То же самое следует сказать об аварийном завершении программы или работы ее отдельных функций. Но тут надо добавить, что в самой программе должна быть заложена функция обработки ошибок, которая, во-первых, записывает в файл ошибок всю необходимую для разработчика информацию, а во-вторых, выдает на экран рекомендации пользователю (известить системного администратора, повторить процедуру и пр.).
Если в МИС не предусмотрена функция обработки аварийных ситуаций с записью в специальный файл или журнал работы МИС, это принципиальный дефект, который необходимо устранить.
Так как зависания и аварийные завершения возникают вследствие обработки определенных данных, разработчику для понимания причин необходимы именно эти данные. Следовательно, у него должен быть доступ к базе данных либо иметься ее копия.
О нелогичных действиях программы или неверном расчете
Проблемы этого вида обычно связаны с ошибками в алгоритме программы. Разработчику тоже нужны конкретные примеры, документированные копиями экранов (скриншотами), и возможность смоделировать аналогичную ситуацию. Если речь идет о неверном соблюдении утвержденных норм (например, неправильный вывод учетной формы), то вместе с описанием проблемы разработчику должна быть предоставлена и ссылка на соответствующий нормативный документ.
Об ошибках в текстах
Разработчику надо сообщить, о каком именно объекте идет речь, указать на ошибку, привести правильное написание и приложить скриншот, на котором видна ошибка. Системный администратор должен понимать, когда речь идет о системном справочнике, за который в ответе именно разработчик, а когда о местном, который составляется и корректируется в ЛПУ.
Пополнение справочников
Такие справочники, как «Сотрудники», «Подразделения», «Медицинские учреждения» и т. п., являются локальными. Остальные унифицированы, то есть являются системными. Обязанность разработчика — сделать локальные справочники удобным инструментом, а системные справочники нуждаются в постоянной поддержке.
Системные справочники, а также все виды текстовых шаблонов — это содержание системы, они должны поддерживаться только централизованно. Если передать их пополнение и коррекцию самим пользователям, то через некоторое время разные учреждения, пользующиеся одной и той же МИС, окажутся в разной информационной среде, не говоря уж о том, что необходимое качество справочников системы при таком порядке работы гарантировать невозможно.
Примечание. Системные справочники нуждаются в постоянной поддержке.
Минимальный вариант структуры справочника — наименование и код. Но ряд справочников содержит и другие структурные элементы, информацию для которых разработчик должен получить либо от пользователя, либо из надежной литературы.
Справочник диагнозов. В этом качестве сегодня, как правило, используется Международная классификация болезней 10-го пересмотра. Но лечащему врачу в отдельных ее разделах недостает детализации. Это и порождает запросы. Их несложно удовлетворить, если воспользоваться оставленной в МКБ-10 возможностью делать подрубрики, не нарушая общей конструкции.
Так, например, эндокринологов не удовлетворяет только общая формулировка «Е23.33. Синдром пустого турецкого седла», так как этот диагноз в истории болезни надо характеризовать наличием тех или иных важных проявлений: ожирением, гиперпролактинемией и т. д. Общее число таких синдромов плюс вариант, когда у пациента есть их комбинация, десять. Отражение имеющегося состояния с помощью текстовой записи означает лишний труд и невозможность последующих выборок по важным признакам. Между тем ничто не мешает к коду E23.33 добавить десять подрубрик от E23.330 до E23.339 и пользоваться всеми преимуществами формализованной информации. Причем все эти диагнозы в официальном отчете попадут в более общую рубрику E23.33.
Подобные проблемы возникают у разных специалистов. Важно, чтобы пользователь не только потребовал пополнить справочник функцией, которой ему не хватает сегодня, а перечислил все возможные варианты детализации.
Справочник средств лечения. Средства лечения совершенствуются постоянно. Если в справочнике чего-то нет, врач должен потребовать дополнения, указав точное наименование медикамента, диеты, лечебного режима, физиотерапевтической процедуры, психотерапевтического тренинга. Здесь важен ряд деталей.
Физио — и психотерапевтические процедуры должны быть поименованы полностью, чтобы смысл был доступен каждому пользователю (в том числе внешним контролерам). Справочник доложен содержать раздел для комментариев (например, о диете, лечебном режиме или психотерапевтическом тренинге).
Отсутствие в справочнике назначаемых врачом медикаментов — частая причина запросов в ходе производственной эксплуатации МИС. Здесь требования к форме запроса должны быть минимальными: достаточно сообщить наименование медикамента. Все остальное разработчик узнает сам, заслуживающие доверия источники (справочник Видаль и энциклопедия «Российские лекарственные средства») общедоступны. Из этих источников он сам выберет и введет в справочник все варианты использования лекарства (лекарственные формы, пути введения, разовые дозы, которые должны появляться в назначениях врача), а также комментарии о показаниях, противопоказаниях и высших дозах. Попытки получать эти данные от врачей обернутся неполнотой информации, дублированием и ошибками. В случаях, когда медикамент в справочнике есть, но нет строки с дозой или с лекарственной формой (например, есть таблетки, а нужны капли, свечи, инъекции), пользователь должен об этом сообщить.
Справочник сигнатур. Предполагается, что ритм применения лечебного средства врач назначает с помощью отдельного справочника сигнатур. Назначение путем дописывания с клавиатуры лишает возможности программно подсчитывать количество принятых медикаментов и стоимость лечения. В этот справочник также придется вносить добавления, например «по 1/4 таблетки», «внутривенно 40 ампул в день» и т. д.
Справочник операций и процедур. Для пополнения разработчику необходимо полное наименование без сокращений и аббревиатур, привычных специалистам. Например, не годится «ТУР» — нужно «трансуретральная резекция». Важно указать анатомическую область, в которой производится операция, чтобы облегчить врачу поиск в справочнике. Надо знать, процедура это или операция, выделять малые операции, которые в истории болезни регистрируются и для учета работы хирургов необходимы, но в официальный отчет не включаются. Наконец, поскольку в официальном отчете необходимо выделять операции, относящиеся к высоким технологиям, да еще и по видам технологий, в запросе надо указывать и эти особенности. Границы понятий «малые операции» и «высокие технологии» подвержены изменениям, поэтому разработчик может предоставить самим пользователям отражать в справочнике эти характеристики — достаточно разрешить медицинскому статистику доступ к соответствующим полям справочника.
Справочник лабораторных и других специальных методов обследования. Требования к дополнениям тут наиболее сложны. Помимо наименования исследования, в котором не должно быть сокращений и аббревиатур (кроме общеупотребительных — ЭКГ, МРТ, УЗИ и т. п.), надо указывать группу, к которой относится исследование (клинические анализы, биохимические и т. п.). Это необходимо для удобного поиска анализа в справочнике, для различных вариантов обработки массива историй болезни: для передачи назначения врача в лабораторию или кабинет, для составления отчетов о работе лабораторий, для анализа лабораторного обеспечения лечебно-диагностического процесса.
Следует сообщить, как описывать результаты исследования в истории болезни и в лабораторном журнале — задать формат описания. Для некоторых исследований кроме полей для текстового протокола и заключения надо указывать номер по журналам лаборатории (таковы, например, анализы на реакцию Вассермана или ВИЧ). Есть исследования, результат которых выражается указанием на наличие или отсутствие факта, например «обнаружено — не обнаружено». Результаты многих серологических анализов оцениваются «крестами» или таблицей с перечнем титров, где указывается, с какого титра лабораторная реакция становится положительной. Эти условия надо учесть, задать, продемонстрировать.
Для анализа, целью которого является единственный числовой результат, надо указать его максимально возможное значение (число необходимых символов), а символьный результат — все его варианты. В обоих случаях надо отразить единицы измерения. Наиболее сложен формат многокомпонентных анализов: они могут включать как числовые, так и символьные компоненты. Для каждого компонента надо задать максимально возможное число символов и единицу измерения. К этому может добавляться символьная строка для дополнений и комментариев — надо определить и ее максимальный размер. Любой формат должен содержать поля для даты и кода лаборанта.
Чтобы ничего не было упущено, для запроса на лабораторное исследование нужно использовать специальный макет, в котором остается заполнить подготовленные поля для наименования анализа, группы, к которой он относится, наименования и единиц измерения каждого компонента, числа необходимых символов.
Совершенствование функций, новые функции, изменения в структуре
Сегодня самая слабая сторона информатизации здравоохранения — отсутствие детально проработанных универсальных представлений о том, что должна делать МИС, каков полный набор требований, которые надо перед нею ставить. Признается даже, будто универсального набора и быть не может, он таков, каким захотят его видеть работники ЛПУ.
Стартовые условия для эксплуатации МИС различны, а возникающие потребности зависят от субъективных устремлений и активности пользователей. Но есть категория запросов, которая определяется общими для всех внешними обстоятельствами. Например, 20 лет назад появились запросы на АРМ врачей общего профиля («семейных врачей»), после 2000 года потребовался автоматизированный учет стоимости лечения и составление реестров по ОМС и ДМС, затем — льготные рецепты, талоны дополнительной информации в поликлинике, усложнились требования к вакцинациям, ужесточился учет ВИЧ-инфицированных. Перечень можно продолжить. И конечно, менялись статистические отчеты ЛПУ. Для всего этого требовались и потребуются новые функции МИС.
Понять, что нужно сделать, когда речь идет о совершенствовании функций или об их дополнении, очень сложно. Решение этих вопросов часто требует личного общения разработчика с пользователем, ставящим задачу.
Степень сложности новых задач определяется ответами на два вопроса: требуется совсем новая функция или нужно совершенствовать имеющуюся? понадобятся ли структурные изменения в электронной истории болезни и в справочниках?
Развитие уже имеющейся функции обычно сводится к дополнению формы: в списке требуется новая графа (например, для сведений о принадлежности к льготной категории), в отчете — дополнительные строки (например, для группы диагнозов) и т. п. Запросы на новые функции разнородны. Если это создание новой отчетной формы, достаточно предъявить разработчику форму и инструкцию по ее заполнению. Сложнее обстоит дело с функциями, которые необходимы для анализа и оценки работы. В основу запроса кладутся изложенные письменно формы таблиц и списков, логические выкладки, предложения насчет места, откуда надо будет вызывать функцию. Разработчику важно объяснить, для чего нужны дополнения, как ими будут пользоваться. Однако пользователи, как правило, ставят задачу схематично, не понимая, что программист может все, только если это «все» хорошо сформулировано.
Например, при формировании статистических таблиц надо понять, что полагается считать по отдельным специалистам, что следует суммировать в формах для подразделения и для учреждения в целом, какие данные будут использоваться для сравнительных оценок.
Новшества могут потребовать изменений в структуре базы данных: добавления новых полей в электронной медицинской карте (истории болезни) и в справочниках или изменения формата уже имеющихся полей. Проиллюстрируем примером последствия для разработчика. Появился СНИЛС, и теперь его нужно указывать в каждой истории болезни. Значит, для этого реквизита нужно сделать специальное поле, внести изменения в функцию ввода данных, проверить выходные формы ввода и добавить поправки в соответствующие алгоритмы. Более того, на федеральном уровне предусмотрены правила кодирования СНИЛС и проверки введенных данных, которые также необходимо уточнить и реализовать в виде программной функции. Все это пользователю без разработчика в голову не придет, а разработчик без пользователя может что-то упустить или наделать лишнего.
Отдельно следует сказать о проблемах, связанных с правкой кода данных и другими вмешательствами в структуру базы данных. Когда архитектура МИС хорошо продумана и многое сделано с запасом, эти крайне нежелательные изменения требуются редко, но полностью застраховаться от них невозможно. Для каждого поля в структуре базы данных устанавливается, какой тип данных можно в него вводить, а также ограничивается максимальный размер поля. Так достигается рациональное использование ресурсов и в значительной степени обеспечивается правильность ввода. На избранный вариант настраиваются программы, работающие с этими данными. Изменение типа или размера поля означает необходимость поправок во всех таких программах. Приходится пересматривать все соответствующие функции, чтобы предупредить возникновение несоответствий во время работы пользователя.
К примеру, всем, кто свои программы сделал при Международной классификации болезней 9-го пересмотра, пришлось при переходе к МКБ-10 не только полностью заменить справочник диагнозов и сформировать новые официальные отчеты, но и переделать функцию ввода диагноза в историю болезни, все документы, куда включается диагноз, все функции выборки из историй болезни по диагнозам.
Преобразованная в соответствии с новыми изменениями программа должна правильно работать и с накопленным до изменений архивом историй болезни, а там формат старый. В редких случаях проблемы удается решить с помощью программных ухищрений, но чаще приходится прибегать к радикальному средству — переформатировать записи в базе данных, приводя их к новому формату хранения.
Последствия вмешательства в действующую структуру могут быть многообразны и разнородны. Кое-что может проявиться только впоследствии в виде неожиданной ошибки. Поэтому изменения особенно важно запоминать, чтобы при отдаленных последствиях быстро распознать природу ошибок.
Замечания о дизайне и интерфейсе
Система общается с пользователем посредством соответствующего интерфейса: экрана и распечаток. Очень важно, как выглядят эти элементы, насколько они информативны. Однако когда пользователь предлагает их изменение, надо понять, что за этим стоит: привычки или объективные неудобства, — и убедиться, что у других пользователей изменения не вызовут замечаний. В спорных случаях лучше оставить вариант, соответствующий предпочтениям разработчика.
В отношении претензий к способам взаимодействия пользователя с МИС можно использовать более определенные критерии. Все, что обещает повысить эргономичность работы, надо использовать — например, уменьшать число нажатий клавиш и щелчков мышью. Если одному удобно работать мышью, а другому клавиатурой, надо сделать доступными обе возможности.
Перечни, из которых делают выбор, должны упорядочиваться так, чтобы обеспечить удобство обзора и дифференциации, в ряде случаев надо дать пользователю возможность упорядочивания по признакам, особенно обширные справочники следует снабжать средствами поиска, использовать поиск по ключевым словам.
Внимания заслуживают и претензии к инструкциям, пояснениям и подсказкам на экране. Информация должна быть понятна всем, кто работает в системе: врачам, медсестрам, статистикам, администратору МИС.
У экранных форм есть функция напоминания о пропущенных сроках, об отсутствии обязательных сведений, о факторах риска и т. д. Однако задачи «напоминалок» ставят только особенно требовательные специалисты. А между тем программист может оказать врачам ценную услугу, если ему известны ситуации, в которых забывчивость проявляется часто или в которых она может привести к последствиям.
И тут для полного понимания запросов и способов их удовлетворения часто требуется прибегать к личным контактам разработчика и пользователя.
Основания для отклонения запроса
Существует несколько групп ситуаций отклонения запроса пользователя.
Программисту нельзя реагировать на устные замечания: время для них истекло с окончанием этапа ввода МИС. В большинстве случаев он не принимает и критику сторонних наблюдателей, так как их предложениям часто недостает ответственности.
Отклоняются предложения удалить что-то лишнее из системы. За такими просьбами почти всегда стоят либо старые привычки, либо отсутствие системного взгляда на ситуацию. Например, лишним могут посчитать то, что просто редко встречается.
Не принимаются запросы с отклонениями от установленных правил и форм подачи, поскольку это может нарушить правильность донесения информации до разработчика.
Часто за замечаниями стоят старые привычки, утратившие значение в условиях автоматизации. Особенно это касается форм документов и шаблонов. Часто просят, например, заканчивать описание статуса пациента диагнозом и планом лечения, хотя это бессмысленно и даже вредно, потому что и диагнозы, и назначения врача вводятся в специальные бланки истории болезни, откуда и выводятся потом в экранные и печатные формы. Разработчику надо либо убедиться, что новые предложения обогащают содержание или совершенствуют его форму, либо их отклонить. В большинстве случаев он сам может оценить содержательность добавлений и поправок, но при необходимости может обратиться к эксперту. Решающим будет голос специалиста, который одновременно является руководителем, то есть несет ответственность за качество лечебно-диагностического процесса, включая культуру документации: заведующего отделением, заместителя главного врача по данному разделу медицины, главного врача, главного специалиста города, руководителя клинической кафедры на базе данного ЛПУ. Этим специалистам необходимо понять серьезность заботы разработчика о поддержке качества МИС.
Запрос пользователя надо удовлетворять, если он делает вклад в содержание МИС, в культуру записей, в удобство работы, в управление деятельностью учреждения, участвует в совершенствовании медпомощи. Казалось бы, верно и обратное: если ничего перечисленного в запросе нет, его надо отклонить. Но существуют ситуации, когда разработчикам приходится вносить в МИС и то, что заведомо не идет на пользу ни врачам, ни их руководителям, ни статистике. Это результат неравномерности информатизации здравоохранения. Ушедшие вперед ЛПУ уже решают информационные задачи без старых средств, а органы здравоохранения требуют предъявлять им эти средства по привычке. И разработчику приходится формировать ненужные больнице талоны амбулаторного пациента, карты, журналы учета, чтобы медикам не пришлось делать это вручную. Но следует помнить, что с течением времени такие функции станут балластом. Определим их:
— формирование официальных учетных форм, чтобы с их помощью составлять отчеты: бумажная история болезни для этого непригодна. Но история электронная как раз и делается так, чтобы из введенных в нее данных можно было создавать любые отчеты. Она, по сути, универсальная учетная форма, позволяющая автоматизировать всю отчетность, при этом и сама легко поддается контролю. Значит, напечатанные с помощью МИС учетные формы ничего нового никому не дают;
— «мониторинги» — другая группа ненужных запрашиваемых функций. С их помощью вышестоящие органы хотят следить за правильностью работы врачей. Однако за работой врачей следят и управляют ею заведующие отделениями, главврач, главные специалисты. Это не только их компетенция — это их ответственность. Они, в отличие от получателей «мониторингов», знают, за чем надо следить и как на отслеженное реагировать. МИС обеспечивает их всей необходимой для контроля информацией, более богатой и глубже проработанной, чем в «мониторингах». Те, кто запрашивает «мониторинги», могли бы воспользоваться именно этой готовой информацией вместо того, чтобы нагружать больницу дополнительной ненужной работой.
Передача запросов разработчику
Чтобы обеспечить взаимопонимание пользователя и разработчика, необходимо каждой стороне назначить сотрудника, задача которого — следить за правильным оформлением и обоснованностью запросов, но при этом не гасить активность пользователей. Со стороны ЛПУ важно выявить причину недовольства, со стороны разработчика — системно осмыслить значение перемен и принять решение о работе с проблемой либо о мотивированном отклонении. Оба специалиста должны убедиться в приемлемости результата.
В ЛПУ данные функции логично поручить системному администратору или заместителю главного врача по информационному обеспечению. Взаимодействие должно обеспечиваться постоянной связью.
Надежность энергетического оборудования и методы термографии.
Современный уровень развития технологий энергетических предприятий предъявляет высокие требования к надежности оборудования, повышению достоверности диагностических методов, а также к эффективной и экономичной эксплуатации данного оборудования. Надежность оборудования базируется на обязательном применении новейших средств, методов контроля и наладки энергомеханического оборудования и требует комплексного подхода к решению инженерно-технических проблем.
Работоспособность энергооборудования, турбин, насосов, вентиляторов, редукторов — это способность оборудования удовлетворять заданным техническим характеристикам в течение определенного момента времени и восстановление его основных характеристик, которая обеспечивается на предприятиях установленной системой технического обслуживания и ремонта (ТОиР).
За последние годы в России произошло несколько крупных техногенных катастроф в энергетической и других отраслях промышленности. Очень приятно, что об этой проблеме говорится на высшем правительственном уровне, но решения и предпринимаемые меры не достаточны для обеспечения надежной и безаварийной эксплуатации промышленного оборудования. Мешает ряд объективных и субъективных проблем, начиная с системных и организационных пробелов и заканчивая подготовкой и технической грамотностью на местах каждого ответственного технического специалиста.
Специалисты компании «Балтех» (Санкт-Петербург) имеют десятилетний опыт по комплексному обеспечению надежности энергомеханического оборудования. Мы разработали комплексную концепцию «Надежное оборудование: 2010», которая призвана облегчить работы, связанные с эксплуатацией и ремонтом роторного (динамического) оборудования начиная с организационных мероприятий и заканчивая прямого взаимодействия энергетиков, технологов и механиков с производителем диагностических средств измерения и инструментов, обеспечивающих надежную эксплуатацию.
Компания «Балтех» является разработчиком и производителем приборов и оборудования, которое в комплексе решает большинство проблем связанных с обеспечение надежности вращающегося оборудования во всех отраслях промышленности. За годы развития нашей компании мы старались учитывать мировой опыт в обслуживании и эксплуатации промышленного оборудования. На сегодняшний день мы разрабатываем, производим и внедряем на предприятия следующие современные решения:
– Термографические и тепловизионные системы BALTECH TR,
– Системы лазерной центровки КВАНТ-Л,
– Приборы и станки для динамической балансировки BALTECH HBM,
– Приборы и комплексы для вибродиагностики машин и механизмов BALTECH CSI 2130,
– Индукционные нагреватели для монтажа и демонтажа подшипников BALTECH HI,
– Стенды для входного контроля качества подшипников качения ПРОТОН-СПП,
– Анализаторы масел и смазок BALTECH CSI 5200.
Уникальность нашего комплексного предложения для промышленных предприятий заключается в том, что мы не только поставляем вышеперечисленный инструментарий для технической диагностики и ремонта, но и проводим обучение непосредственно на предприятии Заказчика или в нашем учебном центре по утвержденному расписанию. Во всех европейских и развитых странах более 50% промышленного оборудования диагностируется и обслуживается по аутсорсинговым схемам подрядными организациями, поэтому компания «Балтех» пять лет назад создала отдел технического сервиса, специалисты которого выполняют термографию (тепловизионную и пирометрическую диагностику), виброналадочные работы (центровка и балансировка) и вибродиагностические работы нашими приборами с выездом в любой регион России и СНГ. В России и странах СНГ, к сожалению, аутсорсинговые схемы по обслуживанию промышленного оборудования начали развиваться только в последние годы, да и то большинство из них аффилированы и не являются независимыми, что не приводит к повышению качества ремонта, и, как следствие, повышению надежности энергомеханического и промышленного оборудования.
На наш взгляд, при выборе внутренней централизованной, децентрализованной или аутсорсинговой схемы ремонта оборудования необходимо подходить с точки зрения безопасности (надежности) и экономической (финансовой) рентабельности сервисных работ. Отталкиваясь от этих тривиальных постулатов необходимо сформировать отдел надежности с группой опытных аналитиков по причинам отказов на самом предприятии, что влечет за собой затраты на покупку приборов и инструментария, ежегодную метрологическую аттестацию, а также хорошую заработную плату специалистам, либо через тендеры заключать договор на сервисное обслуживание энергомеханического оборудования и частично переложить ответственность и вышеперечисленные затраты на подрядчика не вкладываясь в основные фонды и специалистов.
За последние годы в разных отраслях мы наблюдаем курьезные ситуации. Например, сначала предприятие оптимизирую все затраты, а ремонт и диагностика это затратная часть, выводит «за ворота» все технические подразделения в виде отдельных юридических лиц, а потом через несколько лет производит обратную процедуру формирования ремонтного подразделения. т. к. подрядчик старается работать только по годовому договору с утвержденным планом-графиком ремонтных работ, а вне плановые остановы обходятся в десятки раз дороже.
Не зависимо от схемы ремонта энергетического динамического оборудования согласно концепции «Надежное оборудование» (разработчик компания «Балтех», г. Санкт-Петербург) при эксплуатационных и сервисных (ремонтных) работах должен соблюдаться принцип международных систем качества P-D-C-A «ПЛАНИРУЙ-ДЕЛАЙ-ПРОВЕРЯЙ-АНАЛИЗИРУЙ». Согласно данной концепции всегда необходимо найти и проанализировать причину отказа, принять необходимые меры не только по ее локализации с помощью средств функциональной и тестовой диагностики, но и спланировать превентивные мероприятия (указав на слабые технические стороны разработчику, собственным технологам или ремонтному персоналу), чтобы в следующие периоды эксплуатации оборудования эта «болезнь» не повторилась. Таким образом коэффициент надежности оборудования может не только поддерживаться на уровне заложенном при проектировании разработчиком (производителем), но и повышаться за время ремонта машин и механизмов, что приводит к повышению безопасности и эксплуатационной рентабельности. В учебном центре «Балтех» под каждый вид оборудования разработаны отдельные концептуальные программы начиная с расчета экономической целесообразности внедрения методов параметрической диагностики, подбора функциональных приборов и диагностических систем, и заканчивая поставкой с обучением на предприятии данной отрасли. Мировой опыт показывает, что существует всего несколько форм технического обслуживания оборудования. В каждой отрасли процентное соотношение отличается в зависимости от специфики и технологий.
На наш взгляд самым эффективным и простым является метод тепловизионной диагностики (термография). Во всем мире это самый распространенный метод из всех направлений технической дианостики.
Специалистами нашей компании впервые:
-Разработаны методы и методики тепловизионной диагностики электромеханических систем по тепловому полю объекта.
-Разработана классификация видов дефектов энергомеханического оборудования по степени их развития и разбиение по критичности.
-С помощью математических моделей выработаны рекомендации по фактическому подходу к обслуживанию и диагностике энергетического оборудования.
Тепловизионная диагностика выполняется с помощью тепловизоров серии BALTECH TR-01400 и программного обеспечения Протон-Эксперт, разработанных специалистами ООО «Балтех». Суть наших методов тепловизионной диагностики заключается в оценке и прогнозе технического состояния объекта диагностики по результатам прямых или косвенных измерений параметров состояния или диагностических параметров.
Чтобы оценить техническое состояние объекта необходимо знать не только фактические значения параметров, но и соответствующие им нормируемые значения. Разницу между фактическим θфакт и нормируемым θнорм значением мы назвали диагностическим симптомом. Основная сложность в определении критичности диагностического симптома заключается в отсутствии в большинстве случаев норм или эталонов температурных полей (порога температур), а также отсутствие всех известных видов дефектов и их диагностических признаков.
Оптимальное решение задач тепловизионной диагностики сложных объектов может быть получено только в результате анализа множества W состояний, в которых эти объекты могут находиться во время диагностики. Этот анализ был проведен и выполнен теоретически и экспериментально статистическими методами.
Перед проведением тепловизионной диагностики обязательно необходимо производить разбиение электромеханического оборудования на критичные и некритичные, а после проведения диагностики на группы:
-1 группа – допустимо (зеленый),
-2 группа – еще допустимо (желтый),
-3 группа – не допустимо (красный).
Диагностическая модель — это любое знание, используемое в процессе решения диагностической задачи и представленное в определенной форме. Спектр форм диагностических моделей широк — от образов дефектов и их признаков в сознании отдельного специалиста-практика по обслуживанию и ремонту до математических конструкций, реализованных в формальных диагностических программах. Прямая и обратная задачи являются по существу выражением в тепловизионной диагностике двух фундаментальных подходов теории систем.
Задача контроля есть выражение функционального подхода; задача поиска дефектов — выражение структурного подхода. Если используется готовый математический аппарат, для решения первой задачи применяют абстрактные модели (дифференциальное уравнение заданного порядка, аналитическое выражение логической функции, абстрактный конечный автомат), а для решения второй — структурные модели (структурные, комбинационные, последовательностные схемы). Специалисты компании «Балтех» при проведении тепловизионной диагностики всегда используют структурные модели.
Пять подходов к обслуживанию энергетического динамического оборудования.
Если Вы достаточно долго работаете в промышленности, то, возможно, наблюдали все различные формы технического обслуживания. Способы работы обслуживающих или ремонтных подразделений, обычно относятся к пяти категориям:
1) Реактивное (реагирующее) профилактическое обслуживание (РПО);
2) Обслуживание по регламенту или планово-профилактическое обслуживание (ППР);
3) Обслуживание по фактическому техническому состоянию (ОФС);
4) Проактивное или предотвращающее обслуживание (ПАО);
5) Концепция «Надежное оборудование:2010» (комбинированная концепция надежности
ФОРМА ТЕХНИЧЕСКОГО ОБСЛУЖИВАНИЯ ХАРАКТЕРНЫЕ ОСОБЕННОСТИ
Реактивное обслуживание
(затраты 750руб на 1КВт в год) Ремонт или замена оборудования только в случае выхода из строя, либо полной выработки ресурса
Планово-профилактическое обслуживание
(затраты 600руб на 1КВт в год) Планово-периодическое проведение профилактических работ, составление и соблюдение календарного графика
Обслуживание по фактическому состоянию (ОФС)
(затраты 360руб на 1КВт в год) Обслуживание только дефектного оборудования в сочетании с профилактикой внеплановых остановов
Проактивное обслуживание
(затраты 240руб на 1КВт в год) Продление межремонтного интервала и интервала между обследованиями
Концепция «НадО:2010» КОМБИНИРОВАННАЯ КОНЦЕПЦИЯ
Принципиальное значение конечной стоимости затрат на производство работ связанных с ТОиР связано с выбором формы организации системы ТОиР. По просьбе читателей в следующих номерах мы можем более подробно написать о достоинствах и недостатках каждой формы в отдельности.
Отталкиваясь от нашего опыта мы рекомендуем всем предприятиям не зацикливаться на диагностике оборудования, т. к. в большинстве случаев отечественное оборудование в разы перешагнуло свой ресурс, а новое импортное оборудование начинает изнашиваться приблизительно через 4-5 лет после ввода в эксплуатацию (из нашего опыта). К сожалению, сколько бы вы не диагностировали оборудование, техническое состояние его не улучшится. В первую очередь необходимо проводить превентивные меры. В любом случае мы рекомендуем всем техническим специалистам прослушать наши ежеквартальные семинары «Концепция «Надежное оборудование» в Санкт-Петербурге.
Хочется пожелать благополучного развития всем отраслевым и сервисным предприятиям, которое стало возможным благодаря экономическому росту экономики России в последние несколько лет.
Стандарт и нормы по центровке промышленного оборудования очень важная составляющая процедуры виброналадки.