2

Министерство образования Российской Федерации

ТОМСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ

Факультет информатики

Кафедра теоретических основ информатики

ДОПУСТИТЬ К ЗАЩИТЕ В ГАК

Зав. кафедрой, проф., д.т.н.

________________ Л.Ю.

Костюк

«___»_______________ 2008г.

Зайцев Алексей Викторович

РАЗРАБОТКА СИСТЕМЫ АНАЛИЗА ВИДОВ И

ПОСЛЕДСТВИЙ ОТКАЗОВ В ЗДРАВООХРАНЕНИИ

Дипломная работа

Научный руководитель,

Доцент, к.ф-м.н В.А. Лавров

Исполнитель,

Студ. гр. 1431 А.В. Зайцев

Томск - 2008

3

РЕФЕРАТ

Отчет о дипломной работе 40 страниц, 18 рисунков, 2 таблицы, 9 источников, 2

приложения.

FMEA, HFMEA™, КОНТРОЛЬ КАЧЕСТВА, АНАЛИЗ РИСКОВ, МЕДИЦИНА,

ЗДРАВООХРАНЕНИЕ

Объект исследования: система анализа видов и последствий отказов в медицинском

обслуживании.

Цель работы: спроектировать и разработать систему, моделирующую FMEA-анализ

применительно к области здравоохранения.

Основные результаты: система реализована в виде независимого программного продукта.

Эффективность: система позволяет выявить потенциальные нарушения в процессах

медицинского обслуживания до их реального возникновения.

Степень внедрения: в настоящее время система внедряется и используется в различных

медицинских учреждениях США.

4

ОГЛАВЛЕНИЕ

Перечень условных обозначений ................................................... 5

Введение ........................................................................................... 6

1. Анализ предметной области ....................................................... 8

1.1. Методология контроля качества изделий и процессов ..... 8

1.1.1. QFD (Quality Function Deployment –

технология развертывания функций качества) ........... 8

1.1.2. ФСА (функционально-стоимостной анализ) ............... 9

1.1.3. ФФА (функционально-физический анализ)................. 9

1.1.4. FMEA-анализ (анализ видов и последствий отказов) . 9

1.2. HFMEA™-анализ .................................................................. 12

1.2.1. Шаг 1. Определение предмета анализа......................... 13

1.2.2. Шаг 2. Формирование команды .................................... 14

1.2.3. Шаг 3. Графическое описание процесса....................... 14

1.2.4. Шаг 4. Анализ рисков ..................................................... 14

1.2.5. Шаг 5. Мероприятия и оценка результатов ................. 17

2. Проектирование системы............................................................ 18

2.1. Постановка задачи ................................................................. 18

2.2. Средства разработки ............................................................. 18

2.3. Представление и хранение данных...................................... 19

2.4. Моделирование анализа в пошаговом режиме .................. 20

2.5. Экспертные оценки критических событий ......................... 22

Заключение ....................................................................................... 23

Список использованных источников ............................................. 24

Приложение 1. Руководство пользователя.................................... 25

Приложение 2. Руководство программиста .................................. 38

5

ПЕРЕЧЕНЬ УСЛОВНЫХ ОБОЗНАЧЕНИЙ

ОС – операционная система

ФСА – функционально-стоимостной анализ

ФФА – функционально-физический анализ

FMEA (Failure Mode and Effects Analysis) – анализ видов и последствий отказов

HACCP (Hazard Analysis and Critical Control Point system) – анализ рисков и контроль

критических точек

HFMEA™ (Healthcare Failure Mode and Effects Analysis™) – анализ видов и

последствий отказов в здравоохранении

HTML (Hypertext Markup Language) – язык разметки гипертекста

NASA (National Aeronautics and Space Administration) – государственная организация

США, занимающаяся исследованием космоса

QFD (Quality Function Deployment) – технология развертывания функций качества

RCA (Root Cause Analysis) – анализ первопричин

SAE (Society for Automotive Engineers) – общество инженеров-автомобилестроителей

(США)

VA (Department of Veterans Affairs) – Министерство по делам ветеранов (США)

XML (eXtensible Markup Language) – расширяемый язык разметки

6

ВВЕДЕНИЕ

До середины XIX в. в клиниках Европы свирепствовала "родильная горячка". В

лучшие месяцы 3-5%, а в худшие до 30% женщин умирало после родов от этой болезни,

причины которой были неизвестны. В 1846 г. молодой венский врач Игнац Земмельвейс

начал исследования, а в 1847 г. предложил простой метод: врачи и акушеры перед приемом

родов должны были мыть руки раствором хлорной извести. Заметим, это было еще до

открытия Луи Пастера и каких-либо представлений о микробиологии, поэтому в

медицинской практике руки мыли после операций. После введения метода Земмельвейса в

двух клиниках Вены за несколько месяцев смертность снизилась до 0,19%, т.е. в десятки раз.

Земмельвейс, 13 лет активно пропагандируя свой метод, написал книгу, отправил личные

письма многим знаменитостям. Но его метод, несмотря на простоту и доказанную на

практике эффективность, активно отвергали. Результат – сотни тысяч загубленных

человеческих жизней.

В 1856-1863 гг. Грегор Мендель провел большую серию опытов по гибридизации

гороха и статистически обработал результаты. В 1865 г. они были доложены в Брюннском

обществе естествоиспытателей, а затем опубликованы – с ними познакомились все ведущие

ботаники. Так были открыты и обоснованы экспериментально законы наследственности.

Однако в практике селекции растений и животных эти законы почему-то не применялись.

Только в 1900 г. после экспериментов Де Фриза в Голландии, Корренса в Германии и

Чермака в Австрии об этих законах вспомнили, признали их, и они стали основным

инструментом селекции новых видов. Результат – в течение 35 лет работы всех

селекционеров мира были малоэффективными, усилия во многом тратились впустую.

(Заметим в скобках, что в России период растраты этих человеческих ресурсов продлился

еще несколько десятилетий.)

В 1916 г. Альберт Эйнштейн выступил в роли авиационного конструктора и

предложил новый профиль крыла самолета, который потом назвали "кошачьей спиной".

Знаменитый физик предложил эту конструкцию, не познакомившись с хорошо известными в

то время работами Н.Е. Жуковского (1906 г. – на русском и 1910 г. – на немецком языках), а

также с уже применявшимися конструкциями и результатами экспериментов. Однако

авторитет ученого был столь велик, что соответствующий самолет был построен. Испытания

показали отвратительный результат, а летчики-испытатели были рады, что остались в живых

[1].

7

Что общего в этих исторических примерах, список которых можно продолжить? Их

объединяет одно: к соответствующему моменту времени люди уже имели знания,

убедительные экспериментальные доводы относительно правильного, рационального

решения, развития. Но эти знания и опыт были проигнорированы, и в результате –

значительные потери времени, ресурсов и даже человеческих жизней.

По статистическим данным, в США ежегодно умирают от медицинских ошибок

около 120 тыс. человек (для сравнения: 41.2 тыс. гибнут на дорогах, 16.6 тыс. – от падений,

4.1 тыс. – тонут и 3.7 тыс. гибнут на пожарах) [2]. Но чем здравоохранение принципиально

отличается от остальных отраслей промышленности, в которых давно и успешно

применяются различные системы контроля качества и анализа процесса разработки изделий?

Данная работа описывает построение подобной системы контроля качества в

медицинском обслуживании с применением HFMEA™ -анализа.

8

1. АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ

1.1. МЕТОДОЛОГИЯ КОНТРОЛЯ КАЧЕСТВА ИЗДЕЛИЙ И

ПРОЦЕССОВ

По данным исследователей, около 80% всех дефектов, которые выявляются в

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

процессов разработки концепции изделия, конструирования и подготовки его производства.

Около 60% всех сбоев, которые возникают во время гарантийного срока изделия, имеют

свою причину в ошибочной, поспешной и несовершенной разработке [3]. Концепция

всеобщего менеджмента качества требует изменения подхода к разработке новой продукции,

поскольку ставится вопрос не просто поддержания определенного, пусть и достаточно

высокого, уровня качества, а удовлетворенность потребителя. В случае же медицинского

обслуживания речь уже может идти не только о качестве обслуживания, но и о серьезном

ущербе здоровью пациентов и даже человеческих жизнях.

Серьезная работа по повышению деловой культуры, которая необходима для общего

подъема качества во всех звеньях, во многом касается технологий разработки и подготовки

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

пожелания потребителей и сократить сроки разработки и выхода на рынок продукции,

применяют специальные технологии разработки и анализа изделий и процессов [4]:

1.1.1. QFD (QUALITY FUNCTION DEPLOYMENT – ТЕХНОЛОГИЯ РАЗВЕРТЫВАНИЯ ФУНКЦИЙ КАЧЕСТВА)

Основная идея технологии QFD заключается в понимании того, что между

потребительскими свойствами ("фактическими показателями качества") и установленными в

стандартах параметрами продукта ("вспомогательными показателями качества") существует

большое различие.

Технология QFD – это последовательность действий производителя по

преобразованию пожеланий потребителя (фактических показателей качества изделия) в

технические требования к продукции, процессам и оборудованию.

Применение метода QFD позволяет учитывать требования потребителя на всех

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

и, таким образом, повысить степень удовлетворенности потребителя, снизить затраты на

процессы проектирования и подготовки изделий к производству.

9

1.1.2. ФСА (ФУНКЦИОНАЛЬНО-СТОИМОСТНОЙ АНАЛИЗ)

Метод ФСА представляет собой технологию анализа затрат на выполнение изделием

его функций; ФСА проводится для существующих продуктов и процессов с целью снижения

затрат, а также для разрабатываемых продуктов с целью снижения их себестоимости. При

проведении функционально-стоимостного анализа определяют функции элементов

технического объекта или системы и проводят оценку затрат на реализацию этих функций с

тем, чтобы эти затраты снизить.

ФСА – один из методов функционального анализа технических объектов и систем, к

этой же группе методов относятся ФФА (функционально-физический анализ) и FMEA-

анализ.

1.1.3. ФФА (ФУНКЦИОНАЛЬНО-ФИЗИЧЕСКИЙ АНАЛИЗ)

Целью ФФА является анализ физических принципов действия, а также технических и

физических противоречий в технических объектах для того, чтобы оценить качество

принятых технических решений и предложить новые.

Применение ФФА позволяет повысить качество проектных решений, создавать в

короткие сроки высокоэффективные образцы техники и технологий и таким образом

обеспечивать конкурентное преимущество организации.

1.1.4. FMEA-АНАЛИЗ (АНАЛИЗ ВИДОВ И ПОСЛЕДСТВИЙ ОТКАЗОВ)

FMEA-анализ в настоящее время является одной из стандартных технологий анализа

качества изделий и процессов, поэтому в процессе его развития выработаны типовые формы

представления результатов анализа и типовые правила его проведения.

Этот вид функционального анализа используется как в комбинации с ФСА или ФФА,

так и самостоятельно. Он позволяет снизить затраты и уменьшить риск возникновения

дефектов. FMEA-анализ, в отличие от ФСА, не анализирует прямо экономические

показатели, в том числе затраты на недостаточное качество, но он позволяет выявить именно

те дефекты, которые обуславливают наибольший риск потребителя, определить их

потенциальные причины и выработать корректировочные мероприятия по их исправлению

еще до того, как эти дефекты проявятся и, таким образом, предупредить затраты на их

исправление.

FMEA-методология имеет три "точки опоры" [6].

10

A. Принцип. Работа многопрофильной командой специалистов, которые рассматривают

предложенную "эскизную" конструкцию или технологию с разных позиций и доводят ее

до необходимого уровня совершенства.

B. Условие. Команда должна состоять из разнородных специалистов, имеющих

достаточный практический опыт работы с подобными объектами.

C. Методика. FMEA-анализ включает два основных этапа [5]:

1. Построение компонентной, структурной, функциональной и потоковой

моделей объекта анализа;

2. Исследование моделей, при котором определяются:

• потенциальные дефекты для каждого из элементов компонентной

модели объекта; такие дефекты обычно связаны или с отказом

функционального элемента (его разрушением, поломкой и т.д.) или с

неправильным выполнением элементом его полезных функций (отказом

по точности, производительности и т.д.) или с вредными функциями

элемента;

• потенциальные причины дефектов;

• потенциальные последствия дефектов для потребителя; поскольку

каждый из рассматриваемых дефектов может вызвать цепочку отказов в

объекте, при анализе последствий используются структурная и

потоковая модели объекта;

• возможности контроля появления дефектов; определяется, может ли

дефект быть выявленным до наступления последствий в результате

предусмотренных в объекте мер по контролю, диагностике,

самодиагностике и др.;

• параметр тяжести последствий для потребителя B; это – экспертная

оценка, проставляемая обычно по 10-ти балльной шкале;

• параметр частоты возникновения дефекта A; это – также экспертная

оценка, проставляемая по 10-ти балльной шкале;

• параметр вероятности не обнаружения дефекта E; как и предыдущие

параметры, он является 10-ти балльной экспертной оценкой;

наивысший балл проставляется для "скрытых" дефектов, которые не

могут быть выявлены до наступления последствий;

• параметр риска потребителя RPZ; он определяется как произведение

B x A x E; этот параметр показывает, в каких отношениях друг к другу в

11

настоящее время находятся причины возникновения дефектов; дефекты

с наибольшим коэффициентом приоритета риска подлежат устранению

в первую очередь.

Результаты анализа заносятся в специальную таблицу. Выявленные "узкие места", –

компоненты объекта, для которых RPZ будет больше некоторой оговоренной величины, –

подвергаются изменениям, то есть разрабатываются корректировочные мероприятия.

Рекомендуется рассматривать "направления воздействия" корректировочных

мероприятий в следующей последовательности :

1. Исключить причину возникновения дефекта. При помощи изменения

конструкции или процесса уменьшить возможность возникновения дефекта

(уменьшается параметр A).

2. Воспрепятствовать возникновению дефекта. При помощи статистического

регулирования помешать возникновению дефекта (уменьшается параметр A).

3. Снизить влияние дефекта. Снизить влияние проявления дефекта на заказчика

или последующий процесс с учетом изменения сроков и затрат (уменьшается

параметр B).

4. Облегчить и повысить достоверность выявления дефекта. Облегчить

выявление дефекта и последующий ремонт (уменьшается параметр E).

Часто разработанные мероприятия заносятся в последующую графу таблицы FMEA-

анализа. Затем пересчитывается потенциальный риск RPZ после проведения

корректировочных мероприятий. Если не удалось его снизить до приемлемых приделов,

разрабатываются дополнительные корректировочные мероприятия и повторяются

предыдущие шаги.

Появление этой методологии обязано космическим проектам NASA (1963 г.),

авиационно-космической и ядерной техники (60-е, начало 70-х гг.). С 1977 г. (конгресс SAE

на фирме Ford) она получила широкое распространение в автомобильной промышленности

США, Японии и Европы [7]. В настоящее время FMEA-анализ очень широко применяется в

промышленности Японии, США, активно внедряется в странах ЕС, начинает применяться в

России. Его использование позволяет резко сократить "детские болезни" при внедрении

разработок в производство. По оценке журнала "Quality Progress", сегодня не менее 80%

разработок технических изделий и технологий их производства проводится с применением

FMEA-методологии [1].

Заметим, эта методика достаточно просто усваивается специалистами и дает

прекрасные результаты: конструкция и технология сразу получаются "доведенными".

12

Недаром современная зарубежная техника поражает опытных технических специалистов

тем, что она сделана не "другими руками", а "другими мозгами".

Именно FMEA-анализ в силу его особенностей, а также благодаря тому, что он

позволяет выявить и предотвратить отказы до их реального возникновения (что просто

необходимо в медицине), и лег в основу методики HFMEA™ -анализа.

1.2. HFMEA™-АНАЛИЗ

При создании системы безопасности пациентов Министерство по делам ветеранов

США (VA – Department of Veterans Affairs) попыталось привить такую культуру персонала,

которая бы поощряла сообщения о произошедших и потенциальных медицинских ошибках с

целью предотвращения их в будущем. Теперь VA продвинуло эту идею еще на один шаг

вперед.

В 2002 году все медицинские центры министерства впервые опробовали процесс

анализа потенциальных рисков. Это значит, что теперь руководство министерства может не

только изучать причины произошедших происшествий, но и видеть, где они могут

произойти в будущем, и вносить коррективы для их предотвращения.

Этот процесс был разработан летом 2001 года и является гибридом схожих процессов

из пищевой промышленности (HACCP – Hazard Analysis and Critical Control Point system) и

прогнозирующей системы, используемой для оценки безопасности медицинских препаратов

(FMEA – Failure Mode and Effects Analysis).

Так как ни одна из этих систем не подходила полностью для оценки процессов в

здравоохранении, руководство Национального Центра по Безопасности Пациентов (National

Center for Patient Safety) при министерстве решило объединить различные части обеих

систем вместе с принципами, используемыми в RCA (Root Cause Analysis) – системе,

используемой для анализа первопричин произошедших неблагоприятных событий и

нарушений. Объединение с системой RCA, уже используемой в VA, позволило использовать

уже привычные принципы и наработки в новой программе безопасности пациентов, что

облегчило процесс обучения персонала. “Этому можно обучиться за полдня или даже

меньше,” – говорит Эрик Сталхндски, менеджер программы безопасности пациентов,

который принимал участие в её разработке [8].

Новая система получила название Healthcare Failure Mode and Effects Analysis

(HFMEA™) – анализ видов и последствий отказов в здравоохранении. Данный процесс

анализа требует создания многопрофильной команды специалистов для оценки вероятности

появления аварийных ситуаций и тяжести их последствий, а также возможных методов их

13

устранения. Кроме того, команда должна сформулировать рекомендации по управлению

источником опасности, назначить ответственного за реализацию необходимых изменений и

получить подтверждение об их выполнении от медицинского персонала.

Ключевые идеи данной системы и их источники можно представить в виде

следующей таблицы [9]:

Таблица 1. Компоненты HFMEA™ и их источники

Используемая концепция HFMEA™ FMEA HACCP RCA

Работа в команде + + +

Технологическая схема процесса + + +

Отказы и их причины + +

Матрица градаций уровня рисков + +

Определение тяжести и вероятности + ? +

Дерево решений + +

Мероприятия и результаты + ? +

Ответственные лица и согласованное выполнение + ? +

? Хотя данные компоненты и присутствуют в FMEA, они были значительно модифицированы в модели HFMEA™.

HFMEA™ – это 5-ступенчатый процесс, в котором многопрофильная команда

специалистов осуществляет упреждающую оценку процесса в здравоохранении. Команда

использует построение диаграммы течения процесса, матрицу градаций уровня рисков и

дерево решений для идентификации и оценки потенциальных слабых мест. HFMEA™ так же

включает тестирование для того, чтобы удостовериться, что исследуемая система

функционирует эффективно и в ней не появились новые слабые места.

Кратко рассмотрим шаги, которые включает в себя данный анализ.

1.2.1. ШАГ 1. ОПРЕДЕЛЕНИЕ ПРЕДМЕТА АНАЛИЗА

Исследуемый процесс должен быть из разряда опасных или потенциально уязвимых –

достойным для вложения времени и ресурсов команды специалистов. Тема должна быть

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

14

1.2.2. ШАГ 2. ФОРМИРОВАНИЕ КОМАНДЫ

Многопрофильная команда должна включать одного или нескольких специалистов в

исследуемой области, консультанта и руководителя. Многопрофильность позволяет

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

области гарантирует проникновение в суть процесса. С другой стороны, люди, которые не

знают процесс, осуществляют критический обзор общепринятых стандартов и практик, а

также выявляют потенциально слабые места, которые остальные могли пропустить.

Руководитель, который имеет опыт работы в группе, отслеживает, чтобы команда работала

эффективно. Консультант помогает руководителю и вмешивается в процесс, если команда

отклонилась от основной цели.

1.2.3. ШАГ 3. ГРАФИЧЕСКОЕ ОПИСАНИЕ ПРОЦЕССА

Команда строит и проверяет технологическую схему процесса. Для облегчения

дальнейшего анализа каждый шаг процесса нумеруется (например: 1, 2, 3…). Если процесс

комплексный – каждый блок-подпроцесс в свою очередь разбивается на составные части,

которые также обозначаются (1А, 1Б…, 3А, 3Б…).

1.2.4. ШАГ 4. АНАЛИЗ РИСКОВ

Для каждого подпроцесса, определенного на предыдущем шаге, составляется

нумерованный список возможных видов отказов (например: 1А(1), 1А(2)… 3Б(1), 3Б(2)…).

Виды отказов определяются как различные исходы, которые определенный процесс или шаг

подпроцесса может не исполнить при выполнении своей непосредственной задачи.

Например, если шаг подпроцесса – это подтверждение известных аллергий на лекарства, то

виды отказов будут включать: (1) нерегистрация аллергии, (2) неполное определение

аллергий.

Команда должна использовать различные источники и техники для выявления

возможных видов отказов.

Затем для каждого вида отказа определяются тяжесть последствий и частота

возникновения и по матрице рисков устанавливается уровень риска. Тяжесть последствий –

это мера возможного эффекта вида отказа. Другими словами, какое влияние будет оказано на

пациентов или их безопасность в случае возникновения. Категории тяжести включают:

катастрофические, значительные, умеренные и незначительные. Оценки частоты включают:

частые (несколько раз в год), вероятные (несколько раз за 2 года), редкие (иногда в 2 – 5 лет)

и маловероятные (5 – 30 лет).

15

Таблица 2. Матрица градаций уровня рисков

Тяжесть эффекта

Катастрофическая Значительная Умеренная Незначительная

Частый 16 12 8 4

Вероятный 12 9 6 3

Редкий 8 6 4 2

Частота

Маловероятный 4 3 2 1

С помощью дерева решений определяется, требует ли данный вид отказов

дальнейших мероприятий на основании критичности, отсутствии эффективного контроля и

недостаточной вероятности обнаружения:

• Слабое звено (критичность) – определяет, потерпит ли неудачу вся система, если

данная часть процесса нарушится;

• Эффективная мера контроля устраняет или значительно уменьшает вероятность

возникновения отказа;

• Очевидная опасность (выявляемость) определяется как вероятность

распознавания отказа или эффекта от отказа до его возникновения.

Если принято решение о продолжении проработки данного вида отказов, то

перечисляются все его возможные причины. У каждого вида отказов может быть несколько

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

могут быть: неопытный персонал, недостаток квалификации, нечеткое определение

производственных обязанностей, производственные затруднения, плохая поддержка

автоматизированных систем и т.п.

Дерево решений представляет собой последовательность шагов для оценки

конкретного вида отказов или его причин. Оно выступает в роли оценочной функции,

выявляя области, в которых команда должна смягчить опасные места, и области, которые не

требуют пристального внимания, потому что они не столь критичны, высока вероятность

обнаружения, или они уже обладают эффективной мерой контроля. Цель данного шага –

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

исследуемого процесса.

16

Рисунок 1. Дерево решений HFMEA™

17

1.2.5. ШАГ 5. МЕРОПРИЯТИЯ И ОЦЕНКА РЕЗУЛЬТАТОВ

Составляется план мероприятия для каждой причины отказа, для которой необходимо

вмешательство, устанавливаются критерии оценки результатов и назначается лицо,

ответственное за выполнение или контроль выполнения каждого мероприятия. Важной

составляющей данного шага является проверка – эффективно ли функционирует система

после вмешательства и не появились ли в ней или во взаимозависимых системах новые

слабые места.

18

2. ПРОЕКТИРОВАНИЕ СИСТЕМЫ

2.1. ПОСТАНОВКА ЗАДАЧИ

Medical Risk Management Associates, LLC (в дальнейшем Заказчик) была поставлена

задача разработать программный продукт, с помощью которого команда не разбирающегося

профессионально в компьютерной технике персонала могла бы осуществить анализ видов и

последствий отказов различных процессов в медицинском обслуживании. Были определены

следующие основные требования к разрабатываемой системе:

• система должна моделировать HFMEA™ -анализ в пошаговом режиме;

• модульность системы с возможностью дальнейшего расширения набора модулей;

• возможность импорта последовательности шагов процесса в виде простых

текстовых данных;

• возможность экспорта результатов работы программы в формате Microsoft Excel

Spreadsheet;

• возможность распечатки данных с различных этапов работы программы на

принтере;

• программа должна иметь стандартный Windows-интерфейс;

• наличие контекстно-чувствительной подсказки на всех экранных формах;

• программа должна быть написана таким образом, чтобы в дальнейшем Заказчик

мог самостоятельно вносить незначительные изменения в тексты инструкций на

экранных формах, имея минимальные знания о среде разработки;

• продукт должен работать на всех текущий версиях ОС Windows (за исключением

Windows 3.x);

• наличие инсталлятора;

2.2. СРЕДСТВА РАЗРАБОТКИ

Первоначальным пожеланием Заказчика было использовать в качестве средства

разработки приложения среду Microsoft Visual Basic .NET. Главным аргументом в пользу

такого выбора называлась возможность использования средств архитектуры .NET для

работы с XML-данными. Однако в процессе проектирования структуры приложения стало

ясно, что некоторые компоненты пользовательского интерфейса системы требуют более

низкоуровневого программирования. В частности, Заказчик исключил использование

19

программных компонентов третьих фирм, а в программе предстояло реализовать

отображение результатов работы в виде диаграммы Парето и таблицы отчетов с заданной

функциональностью.

В результате было предложено использовать среду разработки Microsoft Visual C++

.NET, что сохраняло возможность использовать архитектуру .NET, но добавляло больше

гибкости при создании элементов пользовательского интерфейса. Сам же пользовательский

интерфейс было решено реализовывать с использованием библиотеки MFC 7.0, которая

предоставляет удобное подмножество классов для работы с архитектурой приложения типа

Document/View (“документ/отображение”).

2.3. ПРЕДСТАВЛЕНИЕ И ХРАНЕНИЕ ДАННЫХ

Кроме организационной текстовой информации (название, описание, контактная

информация, члены команды), данные, которыми представлен текущий анализ в программе –

это некоторое дерево элементов анализа (Рисунок 2).

Основной атрибут каждого элемента – это его текстовое описание. Планируемые и

проведенные мероприятия также характеризуются датой завершения и списком

ответственных лиц в виде простого текстового поля. Кроме того, для некоторых элементов

задаются пары числовых параметров – экспертных оценок до и после проведения

корректирующих мероприятий: для видов отказов и причин это частота возникновения, для

последствий отказов – тяжесть, а для мер контроля – выявляемость.

Так как для некоторых видов отказов может быть перечислено более одной причины

возникновения и/или эффекта, для каждого из которых в свою очередь могут быть указаны

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

заданы комбинированные значения данных параметров, позволяющие ранжировать виды

отказов сами по себе.

Таким образом, на основе характера данных, небольших объемов, а также

планируемых сценариев использования было выбрано внутренноее представление данных в

виде связанных списков структур. В качестве способа хранения ещё на этапе постановки

задачи был задан текстовый формат XML, предназначенный для хранения

структурированных данных. На момент проектирования системы каких-либо стандартов для

представления данных HFMEA™-анализа не существовало. Однако в случае их появления,

приведение к ним текущей схемы XML-представления данных программы (см. Приложение

2) не должно составить особого труда.

20

Рисунок 2. Дерево элементов анализа

Меры контролячастоты

Шаг Nпроцесса

Меры контролявыявляемости

Меры контролячастоты

Меры контролявыявляемости

Меры контролятяжести

Шаг 2

Шаг 1

Планируемыемероприятия

Проведенныемероприятия

Планируемыемероприятия

Проведенныемероприятия

Методы

Методы

Виды отказов

Причины

Последствия

Методы

Методы

2.4. МОДЕЛИРОВАНИЕ АНАЛИЗА В ПОШАГОВОМ РЕЖИМЕ

Для удобства пользователей, а также для облегчения экранных форм, 5 формальных

шагов HFMEA™-анализа были разбиты на более мелкие составные части. При этом

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

только с определенным типом элементов анализа.

В результате, функционально программа была разбита на следующие шаги, каждому

из которых соответствует своя экранная форма:

1. Задание организационной информации (название анализа, краткое описание,

контактная информация, команда);

21

2. Описание исследуемого процесса (отдельно проектного и фактического

вариантов течения процесса);

3. Выбор шагов процесса для последующего анализа;

4. Перечисление видов отказов;

5. Перечисление последствий отказов;

6. Перечисление причин отказов;

7. Перечисление мер контроля;

8. Задание экспертных оценок (отдельно для частоты, тяжести и выявляемости);

9. Ранжирование с помощью диаграммы Парето;

10. Перечисление планируемых мероприятий и методов их выполнения;

11. Перечисление проведенных мероприятий и методов их выполнения;

12. Итоговый отчет (вывод на экран, экспорт, печать).

Для соблюдения заданной последовательности шагов при выполлнении анализа, с

экранной формы текущего шага разрешен переход только на форму следующего за ним. При

этом сохраняется возможность вернуться на любой из предыдущих шагов для

редактирования введенных данных.

Можно сказать, что центральное место в перечисленной последовательности занимает

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

коэффициенту приоритета риска с помощью диаграмы Парето. Диаграмма Парето – это

разновидности столбчатой диаграммы, обычно применяемой для наглядного отображения

рассматриваемых факторов в порядке уменьшения их значимости:

Рисунок 3. Диаграма Парето. Уровни риска видов отказов.

22

Именно на её основе принимается решение – для каких именно видов отказов и/или

их причин необходимо проводить корректирующее вмешательство в первую очередь.

Обычно устанавливается некоторое пороговое значение – критический уровень для

выбранной характеристики, которое задается в процентном выражении от суммарной

величины данной характеристики по всем сравниваемым элементам. По-умолчанию этот

уровень равен 80%.

Оценить качество проведенных мероприятий можно на основе сравнения величин

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

2.5. ЭКСПЕРТНЫЕ ОЦЕНКИ КРИТИЧЕСКИХ СОБЫТИЙ

Стандарт FMEA использует одинаковые шкалы оценок для параметров частоты и

тяжести. Это может приводить к летальным ситуациям, когда отказу с относительно низкой

вероятностью возникновения соответствует относительно низкий коэффициент приоритета

вмешательства (например, частота равна 2, тяжесть 10 – уровень риска 20), в то время как

для незначительного, но достаточно частого отказа вычисляется довольно высокий

приоритет (например, частота 10, тяжесть 3 – уровень риска 30).

Однако в медицине редкое событие, которое ведет к катастрофическим последствиям

(смерть или серьезные повреждения), должно иметь гораздо более высокий уровень риска.

Это значит, что шкала оценки тяжести должна иметь гораздо больший вес, чем шкала оценки

частоты. В процессе проектирования программы было принято решение для событий с

максимальным значением параметра тяжести (для текущей шкалы) при вычислении уровня

риска использовать данное значение, возведенное в квадрат: уровень риска = частота *

тяжесть2.

23

ЗАКЛЮЧЕНИЕ

В результате проделанной работы был разработан и реализован программный продукт

«Failure Mode Analyst», который, в соответствии с требованием Заказчика, моделирует в

пошаговом режиме процесс анализа видов и последствий отказов в здравоохранении

(HFMEA™) и предоставляет визуальные средства контроля течения и результатов данного

процесса. Основным отличием данной системы от других продуктов, применяемых в

области контроля и анализа качества изделий и процессов, является тот факт, что она

изначально разрабатывалась и адаптировалась к сфере медицинского обслуживания, которая

имеет ряд критических особенностей, связанных с непосредственным риском здоровья и

жизни пациентов.

В настоящий момент система внедряется и используется в медицинских учреждениях

США. Medical Risk Management Associates, LLC проводит семинары и тренинги.

24

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1. Розно М.И. Проектирование: с FMEA или без? // Стандарты и качество. – 2001. –

№ 9.

2. Michael G. Crago, Ph.D. Patient Safety, Six Sigma & ISO 9000 Quality Management //

Quality Digest. – 2000. – №11

3. Круглов М.Г., Сергеев С.К., Такташов В.А., Фирстов В.Г., Шишков Г.М.

Менеджмент систем качества. Учебное пособие. – М.: ИПК Издательство

стандартов – 1997.

4. Шиба, А. Грэхэм, Д. Вальден Новое американское тотальное управление

качеством. – 2001.

5. Технологии качества. / ISO9000. Современный менеджмент качества. –

http://www.iso9000.ru

6. Розно М.И. Как научиться смотреть вперед? Внедрение FMEA-методологии //

Методы менеджмента качества. – 2000. – № 6.

7. Анализ видов и последствий отказов. FMEA (третья версия). / Комплект

документов системы QS-9000. Пер. с англ. – Н.Новгород: СМЦ "Приоритет", 2001.

– 72с.

8. Mary Ellen Butler NCPS Implements Risk Analysis Tool Across VA // U.S. Medicine –

August 2002.

9. Joseph DeRosier, Erik Stalhandske, James P. Bagian, Tina Nudell: "Using Health Care

Failure Mode and Effect Analysis: The VA National Center for Patient Safety's Prospec-

tive Risk Analysis System." // The Joint Commission Journal on Quality Improvement

Volume 27 Number 5:248-267, 2002

25

ПРИЛОЖЕНИЕ 1. РУКОВОДСТВО ПОЛЬЗОВАТЕЛЯ

Система представляет из себя единый программный продукт «Failure Mode Analyst»

со стандартным Windows-интерфейсом и поставляется в виде дистрибутива на сменных

носителях.

Системные требования:

• Компьютер с процессором Pentium 90 МГц или выше

• Рекомендуемый объем оперативной памяти 96 Мб и больше

• Не менее 40 Мб свободного места на диск

• Операционная система Microsoft Windows 98/NT/2000/XP

Программа устанавливается посредством запуска исполняемого файла SETUP.EXE из

дистрибутива. Запуск осуществляется через ярлык «Failure Mode Analyst» на рабочем столе

Windows либо выбором соответствующего пункта меню «Пуск».

Рисунок 4. Основное окно программы. Форма «Административные данные»

После запуска на экране появляется основное окно программы (Рисунок 4). Основное

окно программы состоит из следующих частей: меню, панель инструментов, панель выбора

26

текущего шага анализа и рабочей области. В зависимости от выбранного шага анализа

процесса в рабочей области программы отображается соответствующая экранная форма. Для

моделирования пошагового выполнения анализа закладки для форм на панели выбора

текущей формы доступны только для шагов, которые уже завершены. Переход на

следующий шаг осуществляется посредством нажатия на кнопку «Далее» на каждой из

форм. Также общим элементом всех экранных форм является краткая подсказка,

рассказывающая основное назначение данного шага анализа и описывающая основные

элементы формы. Рассмотрим эти формы подробнее.

Административные данные

В данной форме задается название анализа, описание целей и причин. Задается дата

начала анализа. Поле даты окончания анализа должно оставаться незаполненным до полного

завершения процесса анализа. Указываются организационные данные: название учреждения,

адрес. В список членов команды добавляются все участники процесса. Первый участник из

списка автоматически помечается жирным шрифтом как руководитель (список позволяет

производить пересортировку для указания руководителя).

Технологическая схема процесса

На данном этапе перечисляются все шаги исследуемого процесса. Причем отдельно

рассматриваются как проектный вариант процесса, так и реально используемый. Это

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

качество и безопасность.

Сложные части исследуемого процесса разбиваются на составные шаги.

Перемещение отдельных шагов между уровнями вложенности, а так же переупорядочивание

осуществляются с помощью кнопок с соответствующими стрелками (Рисунок 5).

27

Рисунок 5. Форма «Технологическая схема процесса»

Функции

Те шаги процесса, которые на основании дерева решений признаны командой как

требующие дальнейшего рассмотрения, обозначаются как «функции». Эта операция

осуществляется на данной форме посредством проставления галочки напротив

соответствующих шагов процесса (Рисунок 6). По-умолчанию все шаги включены в

дальнейший анализ.

Также на данном шаге можно добавить дополнительные функции, которые не входят

в рассматриваемый процесс изначально, но команда считает необходимым их изучить более

детально.

28

Рисунок 6. Форма «Функции»

Виды отказов

Здесь для каждой функции, определенной на предыдущем шаге, перечисляются

возможные виды отказов. Для этого нужная функция выбирается в списке функций слева и в

центральный список добавляются записи (Рисунок 7).

Стоит отметить, что для каждого элемента анализа программа автоматически задает

метки в виде <тип элемента><номер элемента>. Где номер элемента – это порядковый номер

в списке, а тип элемента соответственно: F – для функций, FM – для видов отказов, E – для

последствий, CF – для причин, D – для мер контроля, R – для планируемых мероприятий и

AT – для проведенных мероприятий. Данные метки отображаются справа от названия

элемента в этой и последующих формах программы. Кроме метки там же отображается и

оценочные параметры, о чем будет рассказано ниже.

Начиная с данной формы в списке элементов анализа в левой части формы,

программа выделяет черным цветом те элементы, для которых перечисляются подчиненные

элементы. Остальные элементы отображаются серым цветом, что облегчает выбор элементов

для анализа.

29

Рисунок 7. Форма «Виды отказов»

Последствия

Подобным же образом на данной форме для каждого вида отказов перечисляются

возможные последствия. По сравнению с предыдущей формой, здесь добавился ещё один

элемент – поле внизу формы, к котором, в отличие от левого списка, где указаны только

элементы до текущего уровня анализа, перечислены все элементы дерева анализа (Рисунок

8).

Кроме того, подобное полное дерево можно посмотреть с помощью дополнительной

формы (Рисунок 9), которая открывается в отдельном окне и доступна через меню View →

HFMEA™ Tree, либо соответствующую кнопку на панели инструментов.

30

Рисунок 8. Форма «Последствия»

Рисунок 9. Форма «Дерево анализа»

31

Причины

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

вызывать (Рисунок 10).

Рисунок 10. Форма «Причины»

Меры контроля

Если для какого-либо вида отказов, его причины или последствия можно определить

некоторую эффективную меру контроля, которая смягчает действие неблагоприятного

фактора или даже полностью его устраняет – её можно указать в данной форме (Рисунок 11).

Мера контроля может влиять на тяжесть, выявляемость либо частоту возникновения

отказа. В зависимости от этого, при добавлении новой меры контроля пользователь должен

выбрать её тип в помощью соответствующей формы (Рисунок 12).

32

Рисунок 11. Форма «Меры контроля»

Рисунок 12. Форма «Выбор типа меры контроля»

Оценочные параметры

В данной форме для перечисленных ранее элементов анализа задаются оценочные

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

(Рисунок 13). Для последствий отказов указывается его тяжесть (сначала величина параметра

до корректирующих мероприятий, а после их проведения – результирующее значение); для

видов отказов и их причин указывается частота возникновения; для мер контроля –

параметр, соответствующий их типу.

33

Программа автоматически вычисляет и показывает в соответствующих полях уровень

риска (равный произведению тяжести и частоты) и коэффициент приоритета риска (равный

произведению уровня риска и выявляемости), показывающий на что именно следует

обратить внимание в первую очередь.

Рисунок 13. Форма «Оценочные параметры»

Все значения параметров выбираются из предварительно заданных таблиц парамет-

ров, которые можно посмотреть и настроить через вспомогательную форму (Рисунок 14).

Форма позволяет не только редактировать существующие таблицы, но и создавать новые.

По-умолчанию в программе предопределены две таблицы: традиционная и созданная

Министерством по делам ветеранов (США).

34

Рисунок 14. Форма «Таблицы оценочных параметров»

Ранжирование по риску

Именно на данной форме можно в наглядной форме увидеть, какие именно виды

отказов или их причины требуют корректирующих действий в первую очередь. С помощью

элементов выбора в левом нижнем углу формы можно выбрать различные варианты

представления данных: для видов отказов либо для их причин, на основании уровня риска

либо коэффициента приоритета риска, до корректирующих мероприятий или после.

Визуализация осуществляется в виде диаграммы Парето – разновидности столбчатой

диаграммы, обычно применяемой для наглядного отображения рассматриваемых факторов в

порядке уменьшения их значимости (Рисунок 15).

Пользователь может также выбрать критический уровень для выбранной

характеристики, которая задается в процентном выражении от суммарной величины данной

характеристики по всем сравниваемым элементам. По-умолчанию этот уровень равен 80%.

35

Рисунок 15. Ранжирование по риску

Планируемые и проведенные мероприятия

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

которые запланированы для снижения риска, а на второй – мероприятия которые были

произведены фактически. Мероприятия могут быть заданы как для вида отказа, так и для его

причин и последствий. Кроме самого мероприятия указывается ответственное лицо и дата

исполнения (Рисунок 16).

Также на этом шаге указываются методы оценки качества корректирующего

воздействия, лицо, ответственное за эту оценку и дата.

36

Рисунок 16. Форма «Планируемые мероприятия»

Отчет

Форма отчета сводит все данные, введенные на предыдущих шагах в единую таблицу

(Рисунок 17). При необходимости текст элементов анализа можно скорректировать прямо

здесь.

Именно в таком виде программа может экспортировать отчет в формате Microsoft Ex-

cel Spreadsheet, а также вывести данные на печать. Печати отчета осуществляется через меню

File → Print, либо соответствующую кнопку панели инструментов. При этом пользователю

предоставляется возможность задать параметры отчета с помощью соответствующей формы

(Рисунок 18). Здесь задается заголовок отчета, а также указывается какие именно данные

необходимо вывести на печать: технологическая схема процесса, список вводов отказов и их

причин, диаграмма Парето и/или итоговая таблица.

37

Рисунок 17. Форма «Отчет»

Рисунок 18. Форма «Параметры печати»

38

ПРИЛОЖЕНИЕ 2. РУКОВОДСТВО ПРОГРАММИСТА

Среда разработки: Microsoft Visual C++ .NET.

Программа реализована на основе архитектуры Document/View с использованием

соответствующих классов библиотеки MFC 7.0.

Основные модули:

PSAnalyst.cpp – модуль класса приложения. Отвечает за инициализацию

программы, загрузку и сохранение параметров.

PSADoc.cpp – модуль класса документа. Отвечает за хранение и сериализацию

данных.

MainFrm.cpp – модуль класса главной формы. Предоставляет единый

интерфейс для всех рабочих форм программы.

Модули экранных форм: PSAViewAdmin.cpp, PSAViewProcess.cpp,

PSAViewFunctions.cpp, PSAViewFailure.cpp, PSAViewEffects.cpp,

PSAViewFactors.cpp, PSAViewControls.cpp, PSAViewScoring.cpp,

PSAViewRanking.cpp, PSAViewRecommend.cpp, PSAViewActions.cpp,

PSAViewReports.cpp

PSAChartCtrl.cpp – модуль класса диаграммы Парето

PSAGridCtrl.cpp – модуль класса таблицы отчета

ExcelExporter.cpp – модуль экспорта в формате Microsoft Excel Spreadsheet

ScoringTablesDlg.cpp – модуль таблиц оценочных параметров

SettingsDlg.cpp – модуль класса диалога настроек программы

Документация программы представлена в виде набора файлов в формате HTML и

файла проекта системы HTML Help Workshop.

XML-схема формата хранения данных: <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.sentinel-event.org/HFMEASchema" xmlns:hfmeas=" http://www.sentinel-event.org/HFMEASchema" > <xsd:element name="PageMax"> <xsd:simpleType> <xsd:restriction base="xsd:integer">

39

<xsd:minInclusive value="0"/> <xsd:maxInclusive value="11"/> </xsd:restriction> </xsd:simpleType> </xsd:element> <xsd:element name="AdminData"> <xsd:complexType> <xsd:all> <xsd:element name="Project" type="xsd:string"/> <xsd:element name="Description" type="xsd:string"/> <xsd:element name="DateBegin" type="xsd:date"/> <xsd:element name="DateEnd" type="xsd:date"/> <xsd:element name="Organizational"> <xsd:complexType> <xsd:all> <xsd:element name="Name" type="xsd:string"/> <xsd:element name="Address" type="xsd:string"/> <xsd:element name="CityState" type="xsd:string"/> <xsd:element name="Country" type="xsd:string"/> <xsd:element name="ZIP" type="xsd:string"/> </xsd:all> </xsd:complexType> </xsd:element> <xsd:element name="Team"> <xsd:complexType> <xsd:element name="Item" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/> </xsd:complexType> </xsd:element> </xsd:all> </xsd:complexType> </xsd:element> <xsd:element name="ProcessFlow"> <xsd:complexType> <xsd:all> <xsd:element name="Optimal" type="hfmeas:ProcessFlowType"/> <xsd:element name="Actual" type="hfmeas:ProcessFlowType"/> <xsd:element name="Discrepancies"> <xsd:complexType> <xsd:element name="Item" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/> </xsd:complexType> </xsd:element> <xsd:element name="Steps" type="hfmeas:FunctionsListType"/> </xsd:all> </xsd:complexType> </xsd:element> <xsd:complexType name="ProcessFlowType"> <xsd:sequence> <xsd:element name="Item"> <xsd:complexType> <xsd:simpleContent> <xsd:extension base="xsd:string"> <xsd:attribute name="level" type="xsd:nonNegativeInteger"/> <xsd:attribute name="checked" type="xsd:boolean"/> </xsd:extension> </xsd:simpleContent> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType> <xsd:complexType name="FunctionsListType">

40

<xsd:sequence> <xsd:element name="Item" minOccurs="0" maxOccurs="unbounded"> <xsd:complexType> <xsd:sequence> <xsd:element name="Title" type="xsd:string"/> <xsd:element name="FailureModes" type="FailureModesListType"/> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType> <xsd:complexType name="FailureModesListType"> <xsd:sequence> <xsd:element name="FailureMode" minOccurs="0" maxOccurs="unbounded"> <xsd:complexType> <xsd:sequence> <xsd:element name="Title" type="xsd:string"/> <xsd:element name="Controls" type="hfmeas:ControlsListType"/> <xsd:element name="Effects" type="hfmeas:EffectsListType"/> <xsd:element name="Factors" type="hfmeas:FactorsListType"/> <xsd:element name="Actions" type="hfmeas:ActionsListType"/> <xsd:element name="AtionsTaken" type="hfmeas:ActionsListType"/> </xsd:sequence> <xsd:attribute name="id" type="xsd:string"/> <xsd:attribute name="OccurrenceBefore" type="xsd:positiveInteger" minOccurs="0"/> <xsd:attribute name="OccurrenceAfter" type="xsd:positiveInteger" minOccurs="0"/> <xsd:attribute name="OccurrenceBeforeCombined" type="xsd:positiveInteger" minOccurs="0"/> <xsd:attribute name="OccurrenceAfterCombined" type="xsd:positiveInteger" minOccurs="0"/> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType> <xsd:simpleType name="hfmeas:ControlType"> <xsd:restriction base="xsd:integer"> <xsd:enumeration value="2"/> <xsd:enumeration value="4"/> <xsd:enumeration value="8"/> </xsd:restriction> </xsd:simpleType> <xsd:complexType name="ControlsListType"> <xsd:sequence> <xsd:element name="Control" minOccurs="0" maxOccurs="unbounded"> <xsd:complexType> <xsd:simpleContent> <xsd:extension base="xsd:string"> <xsd:attribute name="id" type="xsd:string"/> <xsd:attribute name="type" type="hfmeas:ControlType"/> <xsd:attribute name="DetectionBefore" type="xsd:positiveInteger" minOccurs="0"/> <xsd:attribute name="DetectionAfter" type="xsd:positiveInteger" minOccurs="0"/> </xsd:extension> </xsd:simpleContent> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType> <xsd:complexType name="EffectsListType">

41

<xsd:sequence> <xsd:element name="Effect" minOccurs="0" maxOccurs="unbounded"> <xsd:complexType> <xsd:sequence> <xsd:element name="Title" type="xsd:string"/> <xsd:element name="Controls" type="hfmeas:ControlsListType"/> </xsd:sequence> <xsd:attribute name="id" type="xsd:string"/> <xsd:attribute name="SeverityBefore" type="xsd:positiveInteger" minOccurs="0"/> <xsd:attribute name="SeverityAfter" type="xsd:positiveInteger" minOccurs="0"/> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType> <xsd:complexType name="FactorsListType"> <xsd:sequence> <xsd:element name="Factor" minOccurs="0" maxOccurs="unbounded"> <xsd:complexType> <xsd:sequence> <xsd:element name="Title" type="xsd:string"/> <xsd:element name="Controls" type="hfmeas:ControlsListType"/> </xsd:sequence> <xsd:attribute name="id" type="xsd:string"/> <xsd:attribute name="OccurrenceBefore" type="xsd:positiveInteger" minOccurs="0"/> <xsd:attribute name="OccurrenceAfter" type="xsd:positiveInteger" minOccurs="0"/> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType> <xsd:complexType name="ActionsListType"> <xsd:sequence> <xsd:element name="Action" minOccurs="0" maxOccurs="unbounded"> <xsd:complexType> <xsd:sequence> <xsd:element name="Title" type="xsd:string"/> <xsd:element name="Methods" type="hfmeas:MethodsListType"/> </xsd:sequence> <xsd:attribute name="id" type="xsd:string"/> <xsd:attribute name="date" type="xsd:date"/> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType> <xsd:complexType name="MethodsListType"> <xsd:sequence> <xsd:element name="Method" minOccurs="0" maxOccurs="unbounded"> <xsd:complexType> <xsd:simpleContent> <xsd:extension base="xsd:string"> <xsd:attribute name="id" type="xsd:string"/> </xsd:extension> </xsd:simpleContent> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType> </xsd:schema>