Объем работ по интеграции BSL-3/4: что заказчики должны определить до начала проектирования
Проект уровня BSL-3/4 терпит неудачу при вводе в эксплуатацию не из-за низкой производительности оборудования; он заходит в тупик гораздо раньше — когда проектирование продолжается в рамках интеграционного объема работ, который так и не был полностью завершен. Заказчики, полагающие, что само обозначение BSL определяет, что должны делать объект и оборудование, часто обнаруживают на поздних этапах проектирования или во время комплексных испытаний, что ответственность за герметичную оболочку, маршрут передачи или интерфейс управления так и не была возложена ни на кого. Определение объема интеграции до фиксации проекта — это отдельное решение, отличное от выбора оборудования, и оно принадлежит заказчику и проектной команде до того, как можно будет должным образом оценить предложения поставщиков.
Определение объема работ начинается с анализа планируемых работ и оценки рисков
| Данные для определения объема работ | Вклад в сферу интеграции | Граница принятия решения |
|---|---|---|
| Запланированные лабораторные работы | Определяет задачи, которые должна решать комплексная конструкция | Этот аспект следует учитывать в рамках оценки рисков, а не рассматривать как самостоятельный полный набор требований |
| Оценка рисков с учетом конкретных условий объекта | Определяет соразмерные меры контроля биобезопасности и соответствующий объем интеграции | Ссылка на краткое руководство не заменяет оценку рисков проекта или действующие национальные нормы |
| Обозначение BSL | Обеспечивает контекст для определения требований к проекту | Само по себе это обозначение не обеспечивает выполнение всех требований к помещениям, оборудованию, интерфейсам или доказательствам |
Отправной точкой для определения объема интеграции является не обозначение уровня биологической защиты, а работа, которую должна обеспечивать лаборатория. Обозначение BSL-3 или BSL-4 описывает категорию биологической защиты; оно не описывает конкретные патогены, с которыми работают, проводимые процедуры, обрабатываемые объемы или оборудование, которое должно быть подключено к помещению для безопасного обеспечения этой работы. Две лаборатории с одинаковым обозначением могут требовать существенно различающихся объемов интеграции, поскольку предполагаемая работа различается, а рассмотрение обозначения в качестве полного набора требований пропускает этап, который фактически определяет, что необходимо построить.
Именно поэтому оценка рисков служит исходной информацией для определения сферы применения, а не является последующей процедурой обеспечения соответствия. Данная Руководство ВОЗ по биобезопасности в лабораториях, 4-е издание, определяет оценку рисков в качестве основы для принятия соразмерных мер биобезопасности, что означает: именно результаты оценки — а не только сама маркировка уровня биологической защиты — должны лежать в основе решений, касающихся каскадов давления, оборудования для перемещения, зон деконтаминации и точек мониторинга. Если в ходе оценки рисков выявляются конкретные пути переноса, образования отходов или воздействия, связанные с планируемой работой, эти пути становятся элементами, которые должны быть явно учтены в проекте, а не считаться автоматически вытекающими из классификации BSL-3 или BSL-4.
Практическим следствием для владельца является определение последовательности действий. Если запланированные лабораторные работы и их оценка рисков не завершены либо завершены на слишком общем уровне детализации, не позволяющем выявить конкретные пути распространения и точки взаимодействия, любой объем интеграции, составленный исключительно на основе маркировки BSL, будет содержать пробелы, которые впоследствии проявятся в виде незапланированных изменений в проекте. И наоборот, если оценка рисков содержит конкретные сведения о процедурах, агентах и режимах отказа, владелец может использовать её для проверки того, действительно ли предлагаемый объём интеграции является полным, вместо того чтобы полагаться на категорию локальной изоляции в качестве индикатора полноты. Рекомендации на уровне ВОЗ служат обобщённым обоснованием этой логики, но не заменяют оценку рисков, специфичную для конкретного объекта, или применимые национальные правила биобезопасности, которые остаются нормативными актами, которые владелец должен применять напрямую.
Границы зон локализации должны быть обозначены между помещениями и оборудованием
Изоляция не является свойством отдельного помещения; это непрерывная граница, которую необходимо проследить через каждое помещение, каждый коридор и каждое устройство, граничащее с контролируемым пространством. Каскады давления, маршруты перемещения персонала и материалов, пути отвода выхлопных газов, пути отвода жидких отходов и интерфейсы управления — все они пересекают физические и оборудовательные границы, и каждая точка пересечения представляет собой место, где граница может остаться неопределённой, если никто сознательно не нанесёт её на схему.
Составление схемы имеет важное значение, поскольку эффективность локализации зависит от того, где проходит граница: относительно оборудования или относительно ограждающих конструкций помещения. Например, граница давления, проходящая только на уровне помещения, может не учитывать необходимые соотношения давления по всей Лаборатория с модулями уровня BSL-3/BSL-4‘внутренних переходов или на оборудовании, таком как изолирующие заслонки, установленные на вытяжном канале или в системе воздуховодов и предназначенные для обеспечения направленности воздушного потока как в нормальных условиях, так и в случае неисправности. Если граница определяется исключительно на архитектурном уровне, контрольные точки на уровне оборудования рискуют быть отнесены к чужим проблемам; если же она определяется исключительно на уровне оборудования, вклад ограждающих конструкций помещения в формирование этой границы рискует быть принятым на веру, а не проверенным.
Та же логика применима к маршрутам перекачки и каналам отвода отходов. Маршрут перекачки через шлюз, интерфейс перекачки VHP или канал отвода жидких отходов в система обеззараживания сточных вод насколько надежна система в целом, настолько же надежна и её самая слабая точка соединения, а эта точка часто находится на стыке между сферой ответственности объекта и сферой ответственности оборудования. Данная CDC/NIH Биобезопасность в микробиологических и биомедицинских лабораториях (BMBL), 6-е издание, проводит разграничение между системами контроля доступа и воздушных потоков уровня BSL-3 и системами вентиляции, входа и деконтаминации в помещениях для работы в защитных костюмах уровня BSL-4, что служит напоминанием о том, что требуемые характеристики границы локализации меняются в зависимости от уровня локализации и типа объекта — и что граница, правильно спроектированная для одной конфигурации, не может быть без изменений перенесена на другую. Руководство BMBL представляет собой рекомендательные указания, которые следует применять с учетом собственной оценки рисков проекта и местных нормативных требований, а не в качестве универсального заданного значения давления.
Владельцу необходимо решить, были ли все границы давления, трассы передачи, пути отвода, трассы отвода жидких отходов и интерфейсы управления прорисованы как для помещений, так и для оборудования, без каких-либо неявных участков. Непрорисованный участок — это не незначительное упущение; это граница с неопределенным поведением, которую проектировщик не сможет замкнуть, пока кто-нибудь не определит её.
Для служебных функций и элементов управления необходимо указать владельцев интерфейсов
Отображение границы позволяет определить, где она проходит; при этом не устанавливается, кто несет ответственность за её проектирование, создание или проверку. Каждая точка взаимодействия — подключение к инженерным сетям, управляющий сигнал, точка мониторинга, состояние аварийной сигнализации — должна иметь назначенного ответственного, прежде чем её можно будет считать завершённой, поскольку интерфейс без ответственного, как правило, одна сторона считает завершённым, а другая — незавершённым.
Это особенно важно в тех случаях, когда системы управления переходят от управления зданием на уровне объекта к управлению на уровне оборудования, либо когда подача коммунальных ресурсов, таких как электроэнергия, сжатый воздух или дезактивирующая среда, переходит из инфраструктуры объекта в конкретный узел оборудования. Если за интерфейс никто не отвечает, технические условия на одной стороне границы могут быть составлены без учета фактических требований на другой стороне — например, заданное значение управления, определенное системой здания без учета фактических характеристик отклика оборудования, или расчет мощности инженерной сети, выполненный при проектировании объекта без подтверждения фактической потребности оборудования в условиях неисправности. Риск заключается не в том, что интерфейс неверный, а в том, что никто не может сказать, верный ли он, поскольку ни одна из сторон не несла ответственности за согласование требований обеих сторон.
Назначение ответственного лица изменяет характер нерешенного вопроса: он переходит из разряда общих допущений в разряд отслеживаемой ответственности. Если ответственным лицом является проектная группа объекта, роль поставщика оборудования заключается в том, чтобы предоставить данные о взаимодействии достаточно заблаговременно, чтобы проектная группа могла их использовать. Если ответственным лицом является поставщик оборудования, роль проектной группы объекта заключается в подтверждении условий работы инженерных сетей или систем управления, от которых зависит оборудование. Оба варианта могут работать; что не работает, так это оставлять вопрос об ответственности нерешенным, в то время как обе стороны действуют, исходя из собственных предположений о другой стороне.
Задача владельца на данном этапе заключается не в том, чтобы лично урегулировать каждый интерфейс, а в том, чтобы убедиться, что за каждый сопоставленный интерфейс отвечает ровно одна конкретная сторона, а также что информация, необходимая каждой стороне от другой, определена в виде конкретного документа или обмена данными, а не оставлена на усмотрение неформальной координации.
Обязательства поставщиков следует отделять от обязанностей объекта
| Сфера ответственности | Объем работ, который необходимо определить до начала проектирования | Анализ данных интерфейса для выявления |
|---|---|---|
| Коммунальные услуги объекта | Какие инженерные сети входят в состав объекта и где они соединяются с оборудованием | Документы и данные по интерфейсу, которые должна предоставить сторона объекта, а также данные, которые должен предоставить поставщик |
| Строительные работы | Какие строительные работы не входят в объем работ поставщика оборудования | Зафиксированные границы, исключения и документы, влияющие на интеграцию оборудования |
| Результаты работы поставщика оборудования | Какие принятые объекты оборудования входят в комплект поставки поставщика? | Документация поставщиков и данные по интерфейсам, необходимые для экспертизы проекта, комплексных испытаний и сдачи объекта |
После того как интерфейсы определены и распределены по ответственным лицам, следующим решением становится вопрос о том, какая сторона что обеспечивает. Это вопрос, отличный от вопроса о владении: владелец интерфейса определяет его проектную концепцию, тогда как распределение ответственности устанавливает, кто разрабатывает, поставляет и документирует каждую из его сторон. Коммунальные услуги объекта, строительные работы и поставки оборудования — это три отдельные категории объема работ, и проект, в котором они не разграничены четко, рискует рассмотрение предложения когда поставщик и владелец полагают, что ответственность за данный предмет несет другая сторона.
Коммунальные услуги объекта — электроснабжение, водоснабжение, подача сжатых газов, вытяжная вентиляция на уровне здания и аналогичные услуги — как правило, остаются в сфере ответственности объекта до определённой точки подключения, а обязанности поставщика оборудования начинаются именно с этой точки. Строительные работы, включая конструктивные, архитектурные и общие строительные элементы, как правило, полностью выходят за рамки обязательств поставщика оборудования, даже если эти строительные работы напрямую влияют на то, как оборудование интегрируется в пространство. Обязательства поставщика оборудования, после их включения в определённый пакет проекта, сопровождаются собственной документацией и требованиями к данным о сопряжениях, которые необходимы стороне объекта для завершения собственного проектирования с учётом этих обязательств.
Причина, по которой это разделение должно быть явно сформулировано, а не предполагаться, заключается в том, что как пробелы, так и пересечения приводят к затратам времени на координацию, и в обоих случаях требование может фактически остаться без ответственного. Если граница неясна, элемент инфраструктуры или интерфейса может оказаться в зоне, где каждая сторона предполагает, что за него отвечает другая, и проблема выявится только тогда, когда этот элемент понадобится, а его не окажется в наличии. Если распределение ответственности зафиксировано на раннем этапе, его можно проверить до того, как это станет проблемой на объекте. Именно такая информация об объёме работ, специфичная для конкретного проекта, учитывается при рассмотрении конфигурации или коммерческого предложения поставщика: чем чётче границы и данные о взаимодействии, предоставленные заказчиком, тем точнее поставщик может подтвердить, что входит в предлагаемый пакет оборудования — например, в случае лаборатории с модулями BSL-3/BSL-4, изолирующий клапан на тракте вытяжки или расположение системы обеззараживания сточных газов по отношению к инженерным сетям и строительным конструкциям объекта.
Перед началом проектирования владельцу необходимо согласовать не только само разделение, но и документы, а также данные о взаимодействии, которыми каждая сторона должна обмениваться в рамках этого разделения — технические требования, которые объект должен предоставить поставщику, и данные о взаимодействии, которые поставщик должен вернуть, чтобы можно было завершить проектирование объекта с учетом этих данных.
Требования к доказательствам должны учитываться на этапах испытаний и передачи
| Этап проекта | Журнал отслеживания | Решение, которое он поддерживает |
|---|---|---|
| Принятое требование | Утвержденное требование, границы его сферы применения и назначенный ответственный за него | Имеется ли в проекте конкретный элемент, который необходимо включить в экспертизу проекта |
| Анализ проекта | Доказательства соответствия проекта установленным требованиям, включая соответствующие интерфейсы и исключения | Видно ли упущение до начала работ на объекте |
| Комплексное тестирование | Результаты испытаний, связанные с принятым требованием и объемом интеграции | Было ли учтено согласованное требование в ходе комплексных испытаний |
| Передача | Документация по передаче, связанная с данным требованием, и протокол испытаний | Сохраняется ли в окончательном варианте документации цепочка «от требования к доказательству» |
Если согласованное требование не отслеживается на этапах проектирования, тестирования и сдачи проекта, существует риск, что оно будет утрачено, причем никто даже не примет решения об его исключении. Определение объема работ не считается завершённым после согласования требования; оно завершается только тогда, когда данное требование остаётся видимым, с сопутствующими подтверждающими данными, на каждом последующем этапе проекта.
Механизм здесь прост: на каждом этапе проекта по созданию защитной оболочки формируется собственная документация, и если в этой документации отсутствует ссылка на первоначально утвержденное требование, то невозможно подтвердить, что данное требование действительно было учтено, а не незаметно исключено на этапе детального проектирования. Требование, утвержденное на этапе определения объема работ, должно вновь фигурировать на совещании по рассмотрению проекта, где проектная документация демонстрирует, как оно было реализовано; затем — на этапе комплексных испытаний, где результаты испытаний показывают, что оно действительно было проверено в рамках интегрированной системы, а не просто предполагалось работоспособным на основании того, что отдельные компоненты прошли свои собственные проверки; и, наконец, при сдаче проекта, когда в окончательном пакете документации по-прежнему прослеживается связь между исходным требованием и результатами испытаний.
Фактором, превращающим это из формальной детали документации в реальный риск, являются сложность и продолжительность проекта. Если проект имеет небольшое количество интерфейсов и короткие сроки от проектирования до сдачи, неформальный мониторинг может выявить упущенное требование до того, как оно станет критичным. Если же проект включает множество интерфейсов, несколько сторон и более длительные сроки, требование без отслеживаемой истории гораздо легче потерять на переходе между этапами, поскольку ни один документ не содержит полной истории того, почему оно было принято и что обеспечивало его выполнение. Именно здесь становится актуальным различие между тестированием на уровне объекта и на уровне оборудования: требование, связанное с интерфейсом между оборудованием поставщика и системами объекта, требует подтверждения именно в ходе интегрированного тестирования, а не только на основе проверок, проводимых самим поставщиком на заводе, поскольку интегрированное поведение и является тем, что данное требование фактически должно было подтвердить.
Для владельца задача состоит в том, чтобы определить, действительно ли документация по проекту позволяет при сдаче объекта ответить на вопрос, какие из исходных требований были протестированы в рамках интегрированной системы, а какие — нет. Если эта документация является неполной, то этот пробел — не просто неудобство, связанное с оформлением документов, а открытый вопрос о том, было ли данное требование выполнено вообще.
Заморозка проекта зависит от закрытых интерфейсов и зафиксированных исключений
| Проверка окончательного утверждения проекта | Доказательства, подтверждающие | Решение, если вопрос остался нерешенным |
|---|---|---|
| Основа определения объема работ | Планируемые лабораторные работы и оценка рисков проекта отражены в утвержденных требованиях | Оставить затронутые требования открытыми |
| Карта локализации | На карте отображены границы давления, маршруты передачи, пути отвода отработанных газов, пути отвода жидких отходов и интерфейсы управления для всех помещений и оборудования | Оставьте затронутую границу или путь открытыми |
| Права владения интерфейсом | Каждый сопоставленный интерфейс проекта имеет назначенного владельца | Не закрывайте этот интерфейс |
| Распределение ответственности | Коммунальные услуги и строительные работы отделены от объёма работ, выполняемых поставщиками оборудования | Зафиксировать неразрешённую границу области видимости |
| Обмен информацией | Определены необходимые документы и данные интерфейса, предоставляемые каждой стороной | Оставьте затронутый интерфейс открытым до тех пор, пока не будет определён обмен данными |
| Цепочка доказательств | Утвержденные требования учитываются на этапах экспертизы проекта, комплексных испытаний и сдачи объекта | Зафиксировать требование о предоставлении недостающих доказательств до завершения проектирования |
| Исключения | Исключения из проекта явно фиксируются | Не считайте затронутую область закрытой |
«Замораживание проекта» — это момент, когда проект фиксируется в конкретной конфигурации, и он должен зависеть от завершения работ по данному этапу, а не от календарного графика. Замораживание проекта в то время, когда интерфейсы остаются нераспределенными, инженерные сети не выделены из перечня оборудования, а цепочки доказательств не проверены, не приводит к исчезновению этих пробелов; оно лишь переносит их на этапы строительства и ввода в эксплуатацию, где их устранение обходится дороже, а отследить их происхождение становится сложнее.
Условием, определяющим готовность к «заморозке», является то, достиг ли каждый элемент, указанный в определении области применения, закрытого состояния, то есть имеет ли он чётко определённые границы, назначенного ответственного и — в соответствующих случаях — документацию, подтверждающую его связь с проектными и тестовыми работами. Элемент, который по-прежнему находится в открытом состоянии, должен оставаться видимо открытым, а не рассматриваться по умолчанию как решенный только потому, что проектные работы продвинулись дальше. Сюда входят явные исключения: если конкретный путь, интерфейс или обязанность были намеренно вынесены за пределы текущего объёма проекта, такое исключение необходимо зафиксировать в виде решения, а не оставлять для последующих выводов на основании отсутствия какой-либо документации по этому поводу. Незадокументированное исключение впоследствии невозможно отличить от упущенного требования.
Если планируемые лабораторные работы и оценка рисков отражены в утвержденных требованиях, если границы локализации рисков определены как для помещений, так и для оборудования, если для каждого указанного места взаимодействия назначен конкретный ответственный, если обязанности объекта и поставщика четко разграничены с указанием данных о местах их взаимодействия, а также если цепочка доказательств от приемки до испытаний является непрерывной, то проект имеет обоснованные основания для фиксации проекта. Если какой-либо из этих аспектов остается неопределенным, при принятии решения о замораживании проекта данный конкретный пункт следует рассматривать как открытый, а не исходить из предположения, что он разрешится сам собой на этапе детального проектирования или строительства.
Именно на этом этапе объем работ, связанных с оборудованием — например, соответствующие объекты сдачи для модульной лаборатории, изолирующие заслонки на вытяжных трактах или система обеззараживания сточных вод — уже должен быть включен в четко определенное распределение обязанностей с зафиксированными границами взаимодействия, с тем чтобы координация действий с поставщиками на этапе детального проектирования или поставки сводилась к подтверждению уже согласованного объема работ, а не к его пересмотру.
Часто задаваемые вопросы
Q: Достаточно ли классификации BSL-3 или BSL-4 для определения объема интеграции?
A: Нет. Необходимо использовать проектную документацию по лабораторным работам и оценку рисков для конкретного объекта, чтобы преобразовать условия локализации рисков в проектные требования, а затем сверить эти требования с применимыми национальными нормами, а не рассматривать классификацию BSL как исчерпывающую спецификацию.
Q: Что необходимо подготовить заказчику, чтобы предложения поставщиков можно было сравнивать на одинаковых условиях?
A: Подготовьте общий пакет технических заданий, в котором будут определены границы зоны локализации и маршруты, проведено разграничение обязанностей объекта и здания от обязательств поставщиков, указаны ответственные за взаимодействие, перечислены необходимые обмены информацией и зафиксированы исключения. Попросите каждого поставщика указать, как его предложение соответствует данному пакету, и где остаются неясные моменты.
Q: Как следует поступать с интерфейсом, который выходит за рамки отдельного оборудования или объекта?
A: Назначьте ответственного за проектирование интерфейса и зафиксируйте, что каждая сторона должна предоставить и вернуть. Например, в документации должны быть указаны соответствующие границы инженерных сетей или систем управления, документы и данные по интерфейсу, необходимые обеим сторонам, а также доказательства, требуемые для завершения работы над интерфейсом.
Q: Можно ли «заморозить» проект, пока некоторые интерфейсы интеграции остаются нерешенными?
A: Оставьте соответствующий раздел проекта открытым до тех пор, пока не будут зафиксированы его границы, ответственное лицо, необходимый обмен информацией и исключения. «Замораживание» нерешенного интерфейса может скрыть упущение до начала работ на объекте, когда ответственность и изменения в проекте будет сложнее контролировать.
Q: Как заказчики могут предотвратить исчезновение согласованного требования в период между проектированием и сдачей объекта?
A: Определите границы области применения и ответственное лицо для каждого требования, а затем свяжите его с документацией, которая должна быть представлена на этапах рассмотрения проекта, интегрированного тестирования и сдачи объекта. Перед началом работ уточните, кто будет готовить каждую документацию и как она будет соотноситься с согласованным требованием.





















