ТЗ_ЕМИАС-Контингент_ИТОГ. Содержание 1Общие сведения 3 Наименование работ 3 Наименование заказчика и пользователя 3

• Название: Содержание 1Общие сведения 3 Наименование работ 3 Наименование заказчика и пользователя 3
• Дата: 07.03.2018
• Размер: 1.78 Mb.
• Имя файла: ТЗ_ЕМИАС-Контингент_ИТОГ.docx
• Тип: Документы; #37923
• страница: 9 из 16

4Требования к выполнению работ

4.1.Общие принципы выполнения работ

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

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

• 
  анализ полноты описания сервисов (включая состав методов, входных и выходных данных), запланированных к реализации в составе Сервиса «Управление контингентом», на предмет обеспечения исполнения процессов, указанных в п.2.1 настоящего ТЗ;
  
• 
  исследование особенностей функционирования Сервиса, включая количество обрабатываемых Сервисом объектов БД СУПП, частоту обращения к ним, распределение обращений по типам (создание, чтение, редактирование, удаление) и компонентам Системы, являющихся потребителям данных;
  
• 
  обзор научно-технических достижений в области разработки сервисов и работы с базами данных, в части предусматривающей реализацию индивидуальных особенностей функционирования Сервиса, а также уточнение общих требований к Сервисам, переданных Исполнителю;
  

• 
  полученные в ходе научно-исследовательских работ результаты должны быть описаны и согласованы в составе отчетной документации, указанной в п.5.1 настоящего ТЗ для стадий «Научно-исследовательская работа» и «Техно-рабочее проектирование»;
  
• 
  разработать функционально-независимый Сервис «Управление контингентом»;
  
• 
  интегрировать Сервис с существующей СУБД СУПП;
  
• 
  интегрировать Сервис с иными смежными компонентами ЕМИАС, приведенных в п. 3.3.2настоящего ТЗ.
  

4.2.Требования к разрабатываемому Сервису в целом

4.2.1.Требования к структуре и функционированию Сервиса

Ниже представлена разрабатываемая архитектура с обособленным Сервисом «Управление контингентом» (Рисунок ).



Рисунок — Целевая архитектура Системы c Сервисом «Управление контингентом»

Сервис не должен содержать в себе пользовательского интерфейса (User Interface). В Сервисе должен быть организован механизм стандартного для платформы настроечного API.

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

Взаимодействие Системы с остальными сервисами и пользовательским интерфейсом осуществляется через интеграционную шину посредством API WS.

Сервис, выделяемый из СУПП, должен быть разработан как отдельный компонент ЕМИАС, работающий на СУБД СУПП. Логика работы Сервиса не должна влиять на работоспособность текущей реализации СУПП.

Сервис должен содержать слой API атомарных операций, обеспечивающий взаимодействие сервиса с работающей СУБД СУПП. API атомарных операций принадлежит исключительно конкретному сервису. Один Сервис не может использовать API атомарных операций другого Сервиса.

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

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

Для Сервиса должен быть предоставлен набор бизнес-функций, описанных посредством языка описания веб-сервисов WSDL и доступа к ним на языке XML (API WS).

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

Проектирование общесистемных и обобщенных механизмов Сервиса необходимо соотносить с устройством системного ландшафта ЕМИАС.

При выполнении работ должно быть учтено, что интеграционная шина содержит:

• 
  сведения о всех Сервисах, подключенных к ней:
  

• 
  реализуя реестр контрактов и сообщений, которыми оперируют сервисы;
  
• 
  управляя версиями и жизненным циклом сервисов;
  

• 
  необходимые сведения о потребителях сервисов;
  
• 
  сервис с прокси-кодом. Код осуществляет проксирование к существующему сервису, скрывая за шиной его реальное расположение;
  
• 
  модуль мониторинга для отслеживания работоспособности Сервисов и соблюдение требований SLA.
  

4.2.1.1.Назначение и основные характеристики Сервиса «Управление контингентом»

Ниже приведены назначение и основные характеристики Сервиса, которые должны быть реализованы в рамках выполняемых работ (Таблица ).

Таблица  — Назначение Сервиса и основные характеристики

Наименование Сервиса	Назначение	Основные функции
Управление контингентом	Управление сведениями об участках и прикреплениях пациентов	предоставление перечня типов участков; добавление типа участка обслуживания; архивирование типа участка; предоставление списка участков; получение подробной информации об участке; создание участка обслуживания; архивирование участка обслуживания; восстановление из архива участка обслуживания; изменение участка обслуживания; поиск пациентов; идентификация пациента; создание нового пациента; редактирование информации о пациенте; редактирование контактных данных о пациенте; редактирование СНИЛС пациента; архивирование пациента; восстановление архивированного пациента; печать штрихкода и обложки медицинской карты; создание заявления на прикрепление при личном обращении пациента в МО; создание заявления на базовое прикрепление через МПГУ; создание прикрепления к участку; формирование списка заявлений на базовое прикрепление; формирование списка заявлений на базовое прикрепление, поданных через МПГУ; формирование открепленных; формирование списка прикреплений к участкам; смена участка прикрепления; создание прикрепления к специальности; закрытие прикрепления к специальности; перенос группы прикреплений на другой участок; закрытие группы прикреплений к участку

4.2.1.2.Требования к режимам функционирования

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

Система функционирует в следующих режимах:

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

4.2.1.3.Требования по диагностированию системы

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

Сервис должен обеспечивать реализацию функции учета и сбора данных (без отображения) для бизнес-мониторинга. Состав параметров бизнес-мониторинга должен быть определен на стадии техно-рабочего проектирования, согласован с Государственным заказчиком и описан в документе «Пояснительная записка к техническому проекту».

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

4.2.1.4.Перспективы развития, модернизации Сервиса

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

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

4.2.2.Требования к численности, квалификации и режиму работы пользователей, общие требования к персоналу

4.2.2.1.Общие требования к пользователям разрабатываемого Сервиса

Реализованная в рамках предыдущих очередей разработки ЕМИАС детальная спецификация системы прав доступа для пользовательских ролей должна быть уточнена на стадии техно-рабочего проектирования.

Функции разрабатываемого Сервиса должны использоваться следующими пользовательскими интерфейсами КПИ ЕМИАС:

• 
  Главный врач;
  
• 
  Регистратор;
  
• 
  Сотрудник ОМО;
  
• 
  Ответственный за прикрепление;
  
• 
  Регистратор ЛЛО;
  
• 
  Врач;
  
• 
  Пациент.
  

Ниже приведен состав пользователей, взаимодействующих с Сервисом через пользовательский интерфейс (Таблица ).

Таблица — Сервисы и их пользователи

Наименование Сервиса	Пользователи
Управление контингентом	Главный врач, Регистратор ЛЛО, Регистратор, Врач, Ответственный за прикрепления, Сотрудник ОМО, Пациент

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

Требования к уровню подготовки пользователей, взаимодействующих с Сервисом через пользовательский интерфейс ЕМИАС, определены приказом Минздравсоцразвития РФ от 23 июля 2010 г. № 541н «Об утверждении Единого квалификационного справочника должностей руководителей, специалистов и служащих, раздел «Квалификационные характеристики должностей работников в сфере здравоохранения».

Ниже приведено описание уровней квалификации, которым должны соответствовать пользователи, взаимодействующие с разрабатываемым Сервисом (Таблица ).

Таблица — Описание уровней квалификации пользователей, взаимодействующих с разрабатываемым Сервисом

Уровень квалификации	Требования
Пользователь без специальной квалификации	Опыт работы с персональным компьютером и мобильными устройствами
Пользователь средней квалификации	Опыт работы с персональным компьютером на базе операционной системы AltLinux 6.0, а также веб-браузером Mozilla Firefox 24

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

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

Наименование роли пользователя	Квалификация
Главный врач	Пользователь средней квалификации
Врач	Пользователь средней квалификации
Регистратор	Пользователь средней квалификации
Регистратор ЛЛО	Пользователь средней квалификации
Сотрудник ОМО	Пользователь средней квалификации
Ответственный за прикрепление	Пользователь средней квалификации
Пациент	Пользователь без специальной квалификации

4.2.2.3.Требуемый режим работы пользователей

Требования к режиму работы пользователей, взаимодействующих с Сервисом через пользовательский интерфейс ЕМИАС, определяются штатным расписанием и правилами внутреннего трудового распорядка организаций, работниками которых они являются. Требования к режиму работы пользователей, взаимодействующих с решением под ролью «Пациент», не предъявляются.

4.2.2.4.Требования к персоналу

Требования к составу и режиму работы персонала разрабатываемого Сервиса, после проведения приемочных испытаний Сервиса, определяются штатным расписанием и правилами внутреннего трудового распорядка эксплуатирующей организации ЕМИАС. Специальные требования к квалификации и численности персонала, выявленные в ходе проведения научно-исследовательских работ или работ по техно-рабочему проектированию в рамках настоящего ТЗ, должны быть согласованы с Государственным заказчиком и внесены в документ «Руководство администратора».

4.2.3.Показатели назначения

В отчетной документации по текущему ГК в составе документа «Пояснительная записка к техническому проекту» Исполнитель должен привести обоснованную методику расчета указанных в данном разделе показателей назначения и показать расчет данных показателей с использованием характеристик предоставленного Государственным заказчиком технического обеспечения (п.4.4.4 настоящего ТЗ) и характеристик архитектуры разработанного Исполнителем Сервиса, их обеспечивающих.

4.2.3.1.Количество пользователей

К показателям количества пользователей, взаимодействующих с Сервисом через пользовательский интерфейс ЕМИАС, относятся:

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

Ниже приведены пояснения по показателям, связанным с количеством пользователей, взаимодействующих с разрабатываемым Сервисом через пользовательский интерфейс КПИ ЕМИАС, а также их значения, которые должны быть обеспечены архитектурой разрабатываемого Сервиса (Таблица ).

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

Показатель__Определение__Значение'>Показатель	Определение	Значение
Расчетное количество пользователей	Количество пользователей, работа которых должна поддерживаться разработанным Сервисом к моменту сдачи результатов работ по ГК с учетом достижения всех показателей назначения	4 000 000
Расчетное количество одновременно работающих пользователей	Количество одновременно работающих пользователей, работа которых должна поддерживаться разработанным Сервисом к моменту сдачи результатов работ по ГК с учетом достижения всех показателей назначения	200 000
Максимальное количество пользователей	Максимальное количество пользователей, работа которых должна поддерживаться архитектурой разработанного Сервиса	6 000 000
Максимальное количество одновременно работающих пользователей	Максимальное количество одновременно работающих пользователей, работа которых должна поддерживаться архитектурой разработанного Сервиса	300 000

4.2.3.2.Число обрабатываемых объектов

К показателям числа обрабатываемых объектов относятся:

• 
  расчетное количество основных объектов предметной области обрабатываемых за час (по каждому типу обрабатываемого объекта);
  
• 
  расчетное количество основных объектов предметной области обрабатываемых за день (по каждому типу обрабатываемого объекта);
  
• 
  максимальное количество основных объектов предметной области обрабатываемых за час (по каждому типу обрабатываемого объекта);
  
• 
  максимальное количество основных объектов предметной области обрабатываемых за день (по каждому типу обрабатываемого объекта).
  

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

Таблица — Перечень типов объектов, в отношении которых применяется показатель

Объект__Краткое_описание'>Объект	Краткое описание
Сведение о пациенте	Совокупность немедицинских сведений о пациенте, исключая персональные данные
Участок обслуживания	Объект, содержащий информацию об участковом враче, об адресах, которые входят в зону обслуживания данного участкового врача. Все пациенты, прикрепленные к МО, прикрепляются к определенному участку, чтобы обеспечить территориально-участковый принцип оказания медицинской помощи
Заявление на прикрепление к медицинской организации	Заявление на прикрепление к медицинской организации, подаваемое гражданином лично при обращении в медицинскую организацию
Заявление на прикрепление к медицинской организации, поданное в электронном виде	Заявление на прикрепление к медицинской организации, подаваемое гражданином в электронном виде через интернет порталы

Ниже приведены пояснения по показателям, связанным с количеством объектов в разрабатываемом Сервисе (Таблица ).

Таблица — Определения показателей, связанных с числом обрабатываемых Объектов

Показатель	Определение
Расчетное количество основных объектов предметной области обрабатываемых за час (по каждому типу обрабатываемого объекта)	Количество основных объектов предметной области, которое должно обрабатывать приложение за час времени к моменту сдачи ГК с учетом достижения всех показателей назначения
Максимальное количество основных объектов предметной области обрабатываемых за час (по каждому типу обрабатываемого объекта)	Максимальное количество основных объектов предметной области, обработку которых должна обеспечить архитектура приложения в течение часа
Расчетное количество основных объектов предметной области обрабатываемых за день (по каждому типу обрабатываемого объекта)	Количество основных объектов предметной области, которое должно обрабатывать приложение за день к моменту сдачи ГК с учетом достижения всех показателей назначения
Максимальное количество основных объектов предметной области обрабатываемых за день (по каждому типу обрабатываемого объекта)	Максимальное количество основных объектов предметной области, обработку которых должна обеспечить архитектура приложения в течение дня

Ниже приведены значения показателей количества объектов, которые должны поддерживаться разрабатываемым Сервисом (Таблица ).

Таблица — Значения показателей числа обрабатываемых Объектов

Объект	Количество объектов предметной области, обрабатываемых Сервисом
	Расчетное		Максимальное
	За час	За день	За час	За день
Сведения о пациенте	2 500 000	20 000 000	5 000 000	40 000 000
Участок обслуживания	250 000	2 000 000	500 000	4 000 000
Заявление на прикрепление к медицинской организации	6 000	48 000	12 500	100 000
Заявление на прикрепление к медицинской организации, поданное в электронном виде	1 200	9600	2 500	20 000

4.2.3.3.Пропускная способность

К показателям пропускной способности относятся:

• 
  расчетное количество сообщений за час (по каждому информационному потоку);
  
• 
  максимальное количество сообщений за час (по каждому информационному потоку);
  

Перечень объектов, в отношении которых применяется данный показатель, соответствует перечню, обрабатываемых Сервисом объектов, приведенным в разделе 4.2.3.2. Значения показателей пропускной способности разрабатываемого Сервиса, достижение которых должно поддерживаться, соответствует количеству обрабатываемых Сервисом объектов, приведенным в разделе 4.2.3.2.

4.2.3.4.Вероятностно-временные характеристики, при которых сохраняется целевое назначение Сервиса

В штатном режиме функционирования Сервис должен обеспечивать время отклика в соответствии с требованиями, приведенными ниже (Таблица ).

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

Показатель	Средняя величина (не более)	Пиковая величина (не более)
Время отклика для сервисов загрузки, поиска и извлечения данных	3 секунды	10 секунд

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

4.2.4.Требования к надежности

В отчетной документации по текущему ГК в составе документа «Пояснительная записка к техническому проекту» Исполнитель должен привести обоснованную методику расчета указанных в данном разделе показателей надежности и показать расчет данных показателей с использованием характеристик предоставленного Государственным заказчиком технического обеспечения (п. 4.4.4 настоящего ТЗ) и характеристик архитектуры разработанного Исполнителем Сервиса, их обеспечивающих.

4.2.4.1.Показатели надежности

Надежность Сервиса должна определяться уровнем безотказности в работе и способностью к восстановлению работоспособности после отказов.

Ниже приведены регламентные сроки восстановления работоспособности Сервиса в зависимости от степени влияния на его функциональность (Таблица ).

Таблица — Классификация проблем и сроки их устранения

Приоритет проблемы	Описание проблемы	Регламентные сроки устранения проблемы
Блокирующий (Blocker)	Отказ в работе Сервиса, приводящий к невозможности промышленной эксплуатации или приводящий к серьезным сбоям или невозможности эксплуатации интегрированных с ним внешних систем	не более 1 часа
Критический (Critical)	Неработоспособность важных функций Сервиса, оказывающих серьезное влияние на деятельность большого количества пользователей. Значительное падение производительности большой части Сервиса или функций, которые используются большим количеством пользователей	не более 4 часов (при отсутствии проблем с более высоким приоритетом)
Значительный (Major)	Неработоспособность отдельных функций Сервиса, для которых нет простого обходного решения. Значительное падение производительности отдельных функций	не более 12-х часов (при отсутствии проблем с более высоким приоритетом)
Незначительный (Minor)	Незначительная потеря функциональности Сервиса, проблема, которую в настоящий момент можно обойти	не более 40 часов (при отсутствии проблем с более высоким приоритетом)
Тривиальный (Trivial)	Косметический дефект, решение которого необязательно для полноценной работы Сервиса	не более 80 часов (при отсутствии проблем с более высоким приоритетом)

При возникновении аварийных ситуаций обеспечение возможности восстановления данных, которые были записаны в базу данных в результате корректно завершенной транзакции, возлагается на КМИ СЗМ, а именно, на подсистему резервного копирования данных.

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

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

4.2.5.Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов Сервиса

Эксплуатация разрабатываемого Сервиса обеспечивается эксплуатирующей организацией ЕМИАС после проведения процедуры принятия систем в эксплуатацию, действующей у Государственного заказчика.

4.2.6.Требования к защите информации от несанкционированного доступа

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

• 
  уровень информационной безопасности Системы в целом,
  
• 
  уровень защищенности персональных данных в соответствие с Постановлением Правительства Российской Федерации от 1 ноября 2012 года № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»;
  
• 
  класс средств криптографической защиты информации в соответствие с Приказом ФСБ России от 10 июля 2014 года № 378 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств криптографической защиты информации, необходимых для выполнения установленных правительством Российской Федерации требований к защите персональных данных для каждого из уровней защищенности».
  

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

4.2.6.1.Технические требования по защите информации

При разработке Сервиса должны выполняться требования Федерального закона от 27.07.2006 № 152-ФЗ «О персональных данных» и иных нормативных правовых актов в области персональных данных. Сервис должен обеспечивать защиту персональных данных в соответствии с требованиями постановления Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных».

Защита информации, передаваемой по открытым каналам связи, должна осуществляться в соответствии с требованиями нормативно-методического документа «Специальные требования и рекомендации по технической защите конфиденциальной информации» (СТР-К) (Гостехкомиссия России, 2002) с использованием сертифицированных по требованиям безопасности информации криптографических средств защиты.

В «Пояснительной записке к техническому проекту» должны быть определены и отражены требования и решения по обеспечению информационной безопасности Сервиса, определяющие средства защиты информации в части:

• 
  механизмов (способов) аутентификации пользователей в Системе;
  
• 
  обеспечения и контроля прав доступа к защищенным ресурсам и информации;
  
• 
  минимизации прав доступа;
  
• 
  механизмов (способов) аутентификации Системы при взаимодействии с внешними информационными системами;
  
• 
  обеспечения конфиденциальности и целостности передаваемой/принимаемой по каналам связи информации;
  
• 
  управления доступом к защищаемой информации и персональным данным;
  
• 
  резервного копирования и восстановления защищаемой информации;
  
• 
  антивирусной защиты;
  
• 
  разграничения прав доступа, на основании ролевой модели
  
• 
  межсетевого экранирования;
  
• 
  контроля целостности обрабатываемых и технологических данных Системы и ее компонентов.
  

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

При разработке программного кода Исполнитель должен применять методы безопасного программирования, включающие:

• 
  ручную и автоматизированную проверку кода на предмет НДВ;
  
• 
  использование при разработке доверенной аппаратной платформы с функциями защиты от НДВ на системном и прикладном уровне;
  
• 
  контроль версионности исходного кода.
  

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

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

4.2.7.Требования по сохранности информации при авариях

К числу сбоев разрабатываемого Сервиса относятся:

• 
  сбой прикладного программного обеспечения;
  
• 
  сбой из-за ошибок в работе персонала.
  

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

Обеспечение целостности и сохранности данных и обработка нестандартных ситуаций в ходе работы Сервиса (таких как ввод неправильных данных, удаление используемой записи и т.д.) должно обеспечиваться на нескольких архитектурных уровнях Сервиса:

• 
  пользовательские и программные интерфейсы, предоставляющие доступ к функциям Сервиса;
  
• 
  программные модули, реализующие функции Сервиса;
  
• 
  транзакционные механизмы СУБД, механизмы обеспечения целостности данных СУБД.
  

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

Таблица — Способы обеспечения целостности и сохранности данных

Действия в отношении данных	Архитектурный уровень	Способы обеспечение целостности и сохранности данных
Ввод данных	Пользовательские и программные интерфейсы, предоставляющие доступ к функциям Сервиса	Проверка корректности форматов, типов, наличия обязательных параметров
Обработка данных	Программные модули, реализующие функции Сервиса	Логические проверки данных
Хранение данных	СУБД	Механизмы транзакционности и обеспечения целостности, предоставляемые СУБД

Исполнитель должен реализовать вышеперечисленные меры средствами прикладного ПО или предоставить инструкции по реализации данных требований с помощью функций системного ПО. Описание соответствующих решений включается в документы «Пояснительная записка» и «Описание программного обеспечения».

Резервное копирование должно обеспечиваться функциями КМИ СЗМ и штатными средствами используемых СУБД. Информационные ресурсы и программное обеспечение Сервиса, для которых необходимо резервное копирование и восстановление, определяются в процессе разработки и описываются в документе «Технические требования к резервному копированию».

4.2.8.Требования к патентной чистоте

4.2.8.1.Перечень стран, в отношении которых должна быть обеспечена патентная чистота разработанного Сервиса и его частей

Патентная чистота программного комплекса и его частей должна быть обеспечена в отношении патентов, действующих на территории Российской Федерации. Реализация технических, программных, организационных и иных решений, предусмотренных проектом разработки Сервиса, не должна приводить к нарушению авторских и смежных прав третьих лиц.

4.2.8.2.Требования к использованию лицензионного программного обеспечения

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

4.2.9.Требования по стандартизации и унификации

Проводимые работы должны соответствовать следующим требованиям:

• 
  применяемые при доработке Системы технические (форматы данных, протоколы передачи и прочие) и организационные (регламенты, требования, инструкции и т.п.) решения должны быть доступны и документированы в виде, достаточном для независимой реализации третьими сторонами. Применение недокументированных или недоступных решений не допускается;
  
• 
  при выборе применяемых решений преимущество должно отдаваться решениям, основанным на стандартизированных технологиях, т.е. прошедшим процедуру стандартизации и утвержденным в качестве стандарта либо рекомендации каким-либо признанным международным, федеральным, отраслевым, промышленным органом по стандартизации;
  
• 
  при проектировании информационной модели Сервиса должны быть использованы существующие утвержденные (рекомендованные к использованию) ГОСТ и нормативными актами Министерства здравоохранения РФ, и Департаментом здравоохранения города Москвы классификаторы и словари.