Приложение №1 к договору ТЕХНИЧЕСКОЕ ЗАДАНИЕ на
реклама
Приложение №1 к договору ТЕХНИЧЕСКОЕ ЗАДАНИЕ на разработку, внедрение в промышленную эксплуатацию и сопровождение Региональной информационной системы «Электронная медицина», предназначенной для автоматизации учреждений системы здравоохранения Брянской области В настоящем техническом задании (далее – ТЗ) приведены описание, назначение и цели построения Региональной информационной системы «Электронная медицина», технические требования к ее архитектуре, функциональным возможностям, а так же к способам и методам ее реализации в соответствии с требованиями законодательства и методическими рекомендациями Минздравсоцразвития России и утвержденной программы модернизации Брянской области. ТЗ разработано в соответствии со следующими правовыми актами и документами: -Концепция долгосрочного социально-экономического развития Российской Федерации на период до 2020 года (распоряжение Правительства от 17.11.2008 г. № 1662-р); -Приказ Министерства здравоохранения и социального развития Российской Федерации от 30 декабря 2010 г. № 1240н «Об утверждении Порядка и формы предоставления отчетности о реализации мероприятий региональных программ модернизации здравоохранения субъектов Российской Федерации и программ модернизации федеральных государственных учреждений, оказывающих медицинскую помощь»; -Концепция создания единой государственной информационной системы в сфере здравоохранения, утвержденная приказом Министерства здравоохранения и социального развития Российской Федерации от 28 апреля 2011 г. № 364 «Об утверждении Концепции создания единой государственной информационной системы в сфере здравоохранения» (далее – Концепция); -Методические рекомендации Министерства здравоохранения и социального развития Российской Федерации; -Приказ Федерального фонда обязательного медицинского страхования от "07" апреля 2011 г. №79 (с изменениями от 22 августа 2011г); -ГОСТ 34.602-89 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы», утвержденный и введенный в действие Постановлением Госстандарта СССР от 24 марта 1989 г. № 661; -ГОСТ Р ИСО/TС 18308-2008 Информатизация здоровья. Требования к архитектуре электронного учета здоровья; -Федеральный закон РФ от 21.11.2011 г. № 323-ФЗ «Об основах охраны здоровья граждан в Российской Федерации»; -Федеральный закон РФ от 27.07.2006 г. № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; -Федеральный закон от 27.07.2006 г. № 152-ФЗ «О персональных данных»; -ГОСТ Р 52636-2006 Электронная история болезни. Общие положения; -ГОСТ Р 52979-2008 Информатизация здоровья. Состав данных сводного регистра застрахованных граждан для электронного обмена этими данными. Общие требования; -ГОСТ Р 52977-2008 Информатизация здоровья. Состав данных о взаиморасчетах за пролеченных пациентов для электронного обмена этими данными. Общие требования; -ГОСТ Р 52978-2008 Информатизация здоровья. Состав данных о лечебнопрофилактическом учреждении для электронного обмена этими данными. Общие требования; -ГОСТ Р 52976-2008 Информатизация здоровья. Состав первичных данных медицинской статистики лечебно-профилактического учреждения для электронного обмена этими данными. Общие требования; -ГОСТ Р ИСО/ТС 18308-2008 Информатизация здоровья. Требования к архитектуре электронного учета здоровья. Используемые сокращения, термины и определения Электронный сервис РИС ЭМ WEB-браузер WEB-сервер HTML SSL HTTP HTTPS ДМС ОМС ВМП ЛПУ ФОМС МО МЗ АРМ ПО БД МНН КЛАДР ОКВЭД Предоставление в пользование электронной информационной системы и оказание услуг по ее сопровождению Региональная информационная система «Электронная медицина» Программное обеспечение для поиска, просмотра Web-страниц (преимущественно из сети Интернет), для их обработки, вывода и перехода от одной страницы к другой. Например, Google Chrome, Microsoft Internet Explorer, Mozilla Firefox ит.п. Сервер, осуществляющий обработку запросов от WEB-клиентов HypertextMarkupLanguage - это стандартный язык разметки документов во «Всемирной паутине». Все веб-страницы создаются при помощи языка HTML. Язык HTML интерпретируется браузером и отображается в виде документа, удобном для человека SecureSocketsLayer - криптографический протокол, обеспечивающий безопасную передачу данных по сети Интернет. При его использовании создаётся защищённое соединение между клиентом и сервером HyperTextTransferProtocol - протокол прикладного уровня передачи данных в первую очередь в виде текстовых сообщений. Основой HTTP является технология «клиент-сервер», то есть предполагается существование потребителей (клиентов), которые инициируют соединение и посылают запрос, и поставщиков (серверов), которые ожидают соединения для получения запроса, производят необходимые действия и возвращают обратно сообщение с результатом Расширение протокола HTTP, поддерживающее шифрование. Данные, передаваемые по протоколу HTTP, «упаковываются» в криптографический протокол SSL, тем самым обеспечивается защита этих данных Добровольное медицинское страхование Обязательное медицинское страхование Высокотехнологичная медицинская помощь Лечебно-профилактическое учреждение Фонд обязательного медицинского страхования Медицинские организации Министерство здравоохранения Автоматизированное рабочее место Программное обеспечение База данных Международное непатентованное наименование Классификатор адресов России Общероссийский классификатор видов экономической деятельности 1. Общие сведения. Настоящее ТЗ определяет технические требования к составу Региональной информационной системы «Электронная медицина» (РИС ЭМ), а так же перечень автоматизируемых РИС ЭМ функций и процессов, которые могут быть использованы в деятельности учреждений сферы здравоохранения Брянской области. Кроме того они определяют способы предоставления РИС ЭМ на территории Брянской области и требования к исполнителю работ по созданию РИС ЭМ. 1.1. Наименование проекта. «Разработка, внедрение в промышленную эксплуатацию и сопровождение региональной информационной системы, предназначенной для автоматизации учреждений системы здравоохранения Брянской области (Электронная медицина)». 1.2. Основание для создания РИС ЭМ. Реализация мероприятий программы «Модернизация здравоохранения Брянской области» (2011-2012 годы) в части внедрения современных информационных систем в здравоохранение в соответствии с Постановлением Администрации Брянской области от 09 марта 2011г №168 между Администрацией Брянской области, Министерством здравоохранения и социального развития Российской Федерации и Федеральным Фондом обязательного медицинского страхования. 2. Общие требования. 2.1. Общие требования к РИС ЭМ. В рамках работы по созданию, внедрению и поддержке РИС ЭМ должно быть реализовано: - внедрение технологии «интеграционная шина» на базе одного из промышленных решений с размещением приобретаемых компонент программного обеспечения на мощностях оператора региональных информационных ресурсов ЕГИСЗ (далее - Оператор); - приобретаемые компоненты должны включать инструментальное программное обеспечение для настройки, разработки дополнительных модулей и сопровождения «интеграционной шины»; - работы по установке, настройке и вводу в промышленную эксплуатацию должны быть выполнены Поставщиком решения; - в процессе интеграции ресурсов медицинских организаций (МО) Поставщик должен обеспечить доработку унаследованных медицинских информационных систем (МИС), либо обеспечить их замену, с учетом функциональных требований, указанных в настоящем техническом задании; - Поставщик должен обеспечить поставку программных компонент МИС с исходным программным кодом; - при внедрении PACS-систем Поставщик должен размещать: -локальный архив медицинских изображений – на ресурсах Заказчика; -централизованный архив медицинских изображений – на ресурсах Оператора; - Поставщик должен обеспечить интеграцию с Единым порталом государственных и муниципальных услуг в части реализации процедур «Запись на прием к врачу через сеть Интернет» и «Запись на прием к врачу через Инфомат»; - обеспечение функциональных возможностей, указанных в разделе 3 настоящего Технического задания; - обеспечение исполнение работ по информационной безопасности, указанных в разделе 4.3. настоящего Технического задания; - обеспечение бесперебойной работы пользователей РИС ЭМ (Таблица 2.1.); - обеспечение доступа пользователей РИС ЭМ к эксплуатационной документации в электронном виде (для скачивания и (или) просмотра), а именно: «Руководство пользователя»; «Руководство администратора»; Обучающие видеоролики и ролевые инструкции по работе в РИС ЭМ; - проведение группового обучения работе с РИС ЭМ пользователей; - проведение обучения технических специалистов для последующего сопровождения и модернизации системы; - обеспечение работы пользователя с РИС ЭМ в одном из браузеров; - обеспечение сопровождения РИС ЭМ на время гарантийной поддержки согласно требованиям, указанным в Таблице 2.2.; Таблица 2.1. Перечень пользователей РИСЭМ № Тип пользователей Описание пользователей 1. Специализированные организации 2. Пользователи Департамент здравоохранения Брянской области, Территориальный фонд обязательного медицинского страхования Брянской области, ГАУЗ «Медицинский информационно-аналитический центр» Медицинские организации следующих категорий: - оказывающие первичную медико-санитарную помощь; - оказывающие специализированную помощь, в том числе 3. 4. № 1. 2. 3. 4. высокотехнологичную; - оказывающие скорую помощь, кроме специализированной, оказываемой в экстренной или неотложной форме. Граждане Жители Брянской области - для получения возможности самостоятельной удаленной записи на прием в МО Брянской области. Группа сопровождения Технические специалисты центра компетенции, поддержки и модернизации системы Таблица 2.2. Сопровождение РИСЭМ на время гарантийной поддержки Наименование требуемых Описание требований видов работ (услуг) Обеспечение работы Одновременное консультирование не менее 4 сотрудников с многоканальной «горячей единого городского телефонного номера. Режим работы с линий». 8:30 до 17:30 по московскому времени в рабочие дни. Обеспечение оперативной Критические замечания, препятствующие дальнейшей работе доработки функционала РИС в РИС ЭМ – срок устранения не более 1 часа. ЭМ по выявленным Прочие, некритичные доработки – срок устранения не более замечаниям. 2-х рабочих дней. Оперативное внесение Не более 1 дня с момента внесения изменений в РИС ЭМ. изменений в документацию. Максимальное время - не более 20 минут в день простоя системы* - не более 12 часов за весь период предоставления РИС ЭМ * Учитывается время простоя системы, возникшее по вине Поставщика. 2.2.Общие требования и принципы реализации РИС ЭМ. РИС ЭМ должен основываться на следующих принципах: При построении Системы необходимо руководствоваться следующими принципами: -однократный ввод первичной информации в месте ее возникновения и многократное ее использование, в том числе для целей управления здравоохранением; -использование электронных юридически значимых документов в качестве основного источника информации; -обеспечение хранения вводимой информации в базах данных, обеспечение ее целостности и достоверности; -обеспечение совместимости нормативно-справочной подсистемы РИС ЭМ с федеральными информационными системами и возможность обновления данных; -обеспечение совместимости РИС ЭМ с медицинскими информационными Системами, разработки различных производителей, используемых в Брянской области; -обеспечение организации обмена данными с информационными системами органов исполнительной власти федерального и регионального уровня, осуществляющих взаимодействие в рамках задач, связанных с организацией здравоохранения, например, программным комплексом ТФОМС Брянской области; -контроль процесса обработки информации – должно обеспечиваться ведение журнала учета внесения изменений и дополнений в базы данных РИС ЭМ; -возможность получения информации по многокритериальному запросу – получаемые в процессе обработки данные (документы, экранные формы и т.д.) должны содержать всю необходимую и достаточную информацию для принятия управленческих решений на всех уровнях; -обеспечение возможности дальнейшего развития РИС ЭМ; -соответствие программных компонентов, включаемых в РИМ ЭМ и являющихся ее основой, национальным стандартам (ГОСТ), котроые устанавливаются п. 18 «Методических рекомендаций по оснащению медицинских учреждений компьютерным оборудованием и программным обеспечением для регионального уровня единой государственной информационной системы в сфере здравоохранения», утв. Минздравсоцразвития РФ 03.05.2012, в соответствии Концепцией создания единой государственной информационной системы в сфере здравоохранения, утв. приказом Минздравсоцразвития России от28апреля2011г. № 364, а именно: -ГОСТ Р 52636-2006 «Электронная история болезни. Общие положения.»; -ГОСТ Р 52979-2008 «Информатизация здоровья. Состав данных сводного регистра застрахованных граждан для электронного обмена этими данными. Общие требования.»; -ГОСТ Р 52977-2008 «Информатизация здоровья. Состав данных о взаиморасчетах за пролеченных пациентов для электронного обмена этими данными. Общие требования.»; -ГОСТ Р 52978-2008 «Информатизация здоровья. Состав данных о лечебнопрофилактическом учреждении для электронного обмена этими данными. Общие требования.»; -ГОСТ Р 52976-2008 «Информатизация здоровья. Состав первичных данных медицинской статистики лечебно-профилактического учреждения для электронного обмена этими данными. Общие требования.»; -ГОСТ Р ИСО/ТС 18308-2008 «Информатизация здоровья. Требования к архитектуре электронного учета здоровья.»; 2.3.Общие требования к архитектуре РИС ЭМ. РИС ЭМ должна строиться на основе интеграции ресурсов информационных систем МО, при условии их соответствия требованиям настоящего Технического задания, и других участников системы здравоохранения и представлять собой единую систему, включающую в себя ряд подсистем и принципиально позволяющую работать всем пользователям с единой базой данных при использовании определенных подсистем. Если информационные системы МО не соответствуют требованиям настоящего Технического задания, то они подлежат замене. Основными источниками информации в процессе функционирования РИС ЭМ должны являться: 1)справочники и классификаторы, разрабатываемые на федеральном и региональном уровне; 2)оперативные данные, формируемые МО и другими организациями здравоохранения Брянской области; 3)оперативные данные, формируемые ТФОМС Брянской области; 4)программы формирования и анализа форм медицинской статистической отчетности; С учетом неоднородности покрытия территории области сетями передачи данных, РИС ЭМ должна обеспечивать возможность реализации смешанной (централизованно-распределенной) топологии. Такое решение должно позволять использовать в МО, обеспеченных надежными каналами передачи данных, только клиентские рабочие места, без серверов, а в МО, имеющих недостаточно надежные каналы связи, устанавливать отдельные серверы баз данных и приложений. При этом, даже при установке в МО отдельного сервера, должна быть предусмотрена возможность репликации данных на этом сервере с федеральными и региональными компонентами, а так же обмен данными с другими подсистемами и другими МО области. Обмен данными между всеми компонентами, входящими в РИС ЭМ, а также с внешними компонентами и сервисами, происходит через интеграционную шину. Требования к интеграционной шине приведены в разделе 3.1. настоящего Технического задания. Обмен данными происходит в соответствии с регламентами информационного обмена, формируемыми в рамках реализации данного Технического задания, которые закрепляются законодательно на уровне Брянской области. Требования к разработке регламентов информационного обмена и подготовке проекта законодательных актов определяются в разделе 4.2. РИС ЭМ должна обеспечивать централизованное ведение, хранение и репликацию нормативно-справочной информации, включая централизованную синхронизацию с нормативносправочной информацией федеральных сегментов ЕГИСЗ. РИС ЭМ должна обеспечивать функционирование единой базы данных транзакционных МИС регионального фрагмента ЕГИСЗ включая ведение единой ИЭМК пациента в рамках региона, с возможностью доступа к ИЭМК в реальном времени из любого учреждения здравоохранения Брянской области. РИС ЭМ должна иметь модульную открытую архитектуру, обеспечивающую достаточные возможности для масштабирования, повышения производительности и расширения функциональных возможностей. 2.4.Общие требования к структуре и функционированию РИС ЭМ. Функциональная структура предоставляемых в рамках РИС ЭМ систем должна представлять собой комплекс информационных и технологически взаимосвязанных подсистем, позволяющий осуществлять эксплуатацию РИС ЭМ в любом функциональном наборе в зависимости от потребностей. В основу структуры должен быть заложен модульный принцип их построения с открытой архитектурой, обеспечивающей возможность встраивания и взаимодействия с другими системами и подсистемами и интеграция подсистем, в том числе внутри региона, с помощью шины данных. Выбор программных средств, архитектурных и технических решений для РИС ЭМ должен быть сделан, исходя из следующих ограничений: -в основе должно быть предусмотрено использование технологий, обеспечивающих трехуровневую архитектуру: автоматизированные рабочие места пользователей (АРМ), сервер приложений, база (хранилище) данных; -общесистемное программное обеспечение (ПО) должно быть представлено сервером приложений, реализующим бизнес логику и функции оптимизации обработки данных и удовлетворяющим высоким требованиям к надежности, производительности и масштабируемости без пересмотра архитектуры сервиса; -выбранная технологическая платформа должна обеспечивать возможность информационного взаимодействия с внешними системами, а также расширения и внесения изменений в порядок и форматы этого взаимодействия без необходимости смены технологической платформы; -все решения должны представлять собой системы, адаптированные для работы в Web, с интерфейсом на русском языке; -системы должны быть рассчитаны на работу в течение дня не менее 6000 активных пользователей; -системы не должны требовать регулярного администрирования. Штатные средства должны позволять проводить удаленное администрирование базы данных и настройку (при наличии технической возможности доступа к серверам приложений); -системы должны быть рассчитана на хранение в одной БД метаданных и данных с разделением на профили. Под профилями в данном случае понимается отдельное пространство в БД для хранения информации, относящееся к конкретному учреждению здравоохранения. Доступ к профилям должен быть регламентирован таким образом, чтобы пользователи и администраторы конкретного уровня могли иметь право на просмотр и изменение данных относящихся только к профилю конкретного уровня; -пользовательский интерфейс системы должен обеспечивать необходимое качество взаимодействия человека с машиной и комфортность работы персонала; -авторизация должна предусматривать доступ к функциям приложения, а не к серверу базы данных; -внутренние механизмы работы с сервером БД должны предусматривать поддержку непротиворечивости данных при отключениях рабочих процессов пользователей. Таким образом, подсистема должна реализовывать механизм буферирования (транзакционности) внесения изменений в рабочие таблицы сервера базы данных; -наряду с рабочим экземпляром подсистемы должна быть предусмотрена возможность по развертыванию на тех же серверах тестового экземпляра, что позволит проводить испытания некоторых функций подсистемы до того, как они будут применены в рабочей среде; -интеграция на всех уровнях должна происходить с использованием технологической шины данных по определенным сценариям взаимодействия. 2.5.Общие требования по защите информации в РИС ЭМ Средства РИС ЭМ должны обеспечивать сохранность данных в соответствии с законодательством РФ. Вход в пользовательскую часть РИС ЭМ и дальнейшая работа в нем должны осуществляться только при указании имени пользователя и его пароля. Для каждого пользователя должна быть назначена одна или более ролей, которые этот пользователь выполняет в РИС ЭМ. В РИС ЭМ должна быть предусмотрена возможность настройки для каждой пользовательской роли прав доступа к информационным ресурсам и выполнения определенных операций. При необходимости, для каждого справочника и архива документов должны определяться права на создание в них новых записей, их редактирование и удаление. Для каждой пользовательской роли должна быть предусмотрена возможность задать специфичное главное меню РИС ЭМ с набором тех функций, которые доступны данной роли. Поставщик должен предварительно настроить список пользовательских ролей в соответствии с предоставленной Заказчиком информацией. Технические и программные средства должны удовлетворять устанавливаемым в соответствии с законодательством Российской Федерации требованиям, обеспечивающим защиту информации. Безопасность персональных данных при их обработке в информационных системах обеспечивается с помощью системы защиты персональных данных, включающей организационные меры и средства защиты информации (в том числе шифровальные (криптографические) средства, средства предотвращения несанкционированного доступа, утечки информации по техническим каналам, программно-технических воздействий на технические средства обработки персональных данных), а также используемые в информационной системе информационные технологии. В соответствии с Федеральным законом от 27 июля 2006 г. № 152-ФЗ «О персональных данных», совместным приказом Федеральной службы по техническому и экспортному контролю, Федеральной службы безопасности Российской Федерации, Министерства информационных технологий и связи Российской Федерации от 13 февраля 2008 года № 55/86/20 «Об утверждении Порядка проведения классификации информационных систем персональных данных» РИС ЭМ должна быть классифицирован по классу К1. 2.6.Общие требования к патентной чистоте РИС ЭМ. Функционирование РИС ЭМ должно обеспечиваться только теми программными компонентами, которые приобретены (получены) и используются без нарушений лицензионных соглашений. Это требование обеспечивает соблюдение авторских прав разработчиков используемых программных компонентов. Поставляемое программное обеспечение и предоставление неисключительных прав на дополнительные подсистемы должны сопровождаться документацией (лицензионным соглашением), подтверждающей право участника поставлять данную продукцию. Поставщик обязан передать права на модификацию разработанной системы, а также предоставить открытый код для Заказчика для дальнейшей модернизации системы. Передача всего необходимого для функционирования РИС ЭМ программного обеспечения (компонентов) должна оформляться лицензионным соглашением. 2.7.Справочники и классификаторы РИС ЭМ. В РИС ЭМ должны быть доступны справочники, в том числе: -Аллергологический анамнез; -Анализы; -Анамнезы; -Анатомо-терапевтически-химическая классификация; -Вид обращения; -Виды Анестезии; -Виды госпитализации; -Виды инвалидности; -Виды налогов; -Виды нетрудоспособности; -Виды обращений; -Виды оплаты; -Виды отделений; -Виды посещений; -Виды стационарной помощи; -Виды травм; -Вредности; -Вредные факторы; -Географические понятия (КЛАДР); -Группы крови; -Д-группы пациентов; -Должности; -Заболевания и зависимости; -Заключения врача; -Исследования; -Источники финансирования; -Исход госпитализации; -Исходы обращений и причины незавершённости; -Исходы операции; -Категории диспансерного наблюдения; -Категории; -Квалификационных категорий врачей; -Клинико-терапевтические группы; -Конституции; -Контрагенты; -Список МО; -Льготы; -Манипуляции; -Международный классификатор болезней, редакция 10 (МКБ10); -Объективные статусы; -ОКВЭД; -Причины госпитализации; -Профили коек; -Профили отделений; -Процедуры; -Режимы стационара; -Результат посещения; -Рекомендации; -Семейные положения; -Симптомокоплексы; -Сопутствующие заболевания; -Состояния регистрации; -Социальные положения; -Специальности по образованию; -Специальности; -Страховые компании; -Тип госпитализации; -Тип посещения; -Тип транспортировки пациента; -Типы образований; -Типы отделений; -Типы персональных документов; -Типы реестров; -Услуги; -Характеры заболеваний; -Цели посещения; -Цели прикреплений. 2.8.Безопасность работ и результатов работ Все технические решения, использованные при разработке и доработке компонентов РИС ЭМ, а также требования к аппаратному обеспечению, должны соответствовать действующим нормам и правилам техники безопасности, пожаробезопасности и взрывобезопасности, а также охраны окружающей среды при эксплуатации. Факторы, оказывающие вредные воздействия на здоровье со стороны всех элементов РИС ЭМ (в том числе инфракрасное, ультрафиолетовое, рентгеновское и электромагнитное излучения, вибрация, шум, электростатические поля, ультразвук строчной частоты и т.д.), не должны превышать действующих норм (СанПиН 2.2.2./2.4.1340-03 от 03.06.2003 г.). Соответствие предлагаемых в составе регионального сегмента ЕГИСЗ программных компонентов, являющихся основой создаваемой системы, требованиям ГОСТ должно быть подтверждено копиями сертификатов соответствия прилагаемых в составе заявки. При возникновении сбоев в аппаратном обеспечении, включая аварийное отключение электропитания, система должна автоматически восстанавливать свою работоспособность после устранения сбоев и корректного перезапуска аппаратного обеспечения (за исключением случаев повреждения рабочих носителей информации с исполняемым программным кодом). РИС ЭМ должна обеспечивать корректную обработку ошибочных ситуаций с возможностью дальнейшего продолжения работы без аварийного закрытия подсистем, за исключением случаев, когда ошибка делает дальнейшую работу в рамках пользовательской сессии невозможной. Надежность специального прикладного программного обеспечения должна быть обеспечена комплексом мероприятий отладки, поиска и исключения ошибок на этапах доработки функциональной архитектуры и приемо-сдаточных испытаний. 3.Требования к автоматизируемым функциям (подсистемам) РИС ЭМ. В данном разделе описаны минимальные требования по функциональности. Детальные требования к составу информационных полей каждой подсистемы в рамках выполнения требований настоящего Технического задания должны быть зафиксированы в частных технических заданиях, формируемых Поставщиком для разработчиков локальных МИС. 3.1. Платформа «интеграционная шина». 3.1.1. Общие требования к архитектуре компонента. Платформа «интеграционная шина» должна обеспечивать взаимодействие всех интегрируемых приложений через единую точку и являться составной частью ЕГИСЗ Брянской области. Платформа должна поддерживать трехуровневую архитектуру: -Сервер приложений. Должен обеспечивать открытый API для внешних систем, а также пользовательский интерфейс для администрирования платформы шины; -Сервер управления базой данных. Сервер должен хранить метаданные в структурированном виде; -Сервер управления неструктурированной информацией; -Сервер управления хранилищем. Должен обеспечивать взаимодействие между сервером приложений, хранением метаданных, контента (содержимым), а также неструктурированных данных. Сервер должен определять безопасный доступ к информации. Контент (содержимое) должен храниться на файловых хранилищах. Платформа должна поддерживать кроссплатформенность. Платформа должна функционировать в операционной среде Linux, Microsoft Windows Server, Oracle Solaris, AIX, HP-UX и под управлением следующих систем управления базами данных – Oracle, Microsoft SQL, DB2, Sybase. Платформа должна предоставлять возможность гибкого и оперативного расширения интегрируемых систем. Платформа должна состоять из следующих компонент: 1.Медицинская интеграционная сервисная шина 2.Регистр и репозитории регионального архива медицинских документов, в составе которых должны быть подсистемы архива медицинских изображений, электронных медицинских карт и оцифрованных медицинских документов, а также административные и управленческие реестры регионального сегмента ЕГИСЗ, в том числе реестр врачей и медицинского персонала, реестр паспортов медицинских организаций Брянской области, региональные НСИ. 3.Система поиска документов. 4.Визуальные обозреватели для просмотра содержимого репозиториев регионального уровня. 3.1.2.Требования к Медицинской интеграционной сервисной шине. Интеграционная сервисная шина должна обеспечивать транспортную инфраструктуру и интероперабельность информационного обмена между федеральным сегментом ЕГИСЗ, компонентами электронного правительства Брянской области, информационными ресурсами ЛПУ Брянской области, в том числе с Региональной медицинской информационной системой и унаследованными МИС. Интеграционная сервисная шина должна поддерживать сервис-ориентированную архитектуру Интеграционная сервисная шина должна поддерживать открытые интерфейсы обмена медицинской информацией для подключения адаптеров протоколов (DICOM 3.0, WADO, HL7 v2 и v3), а также промышленные стандарты обмена информацией и построения веб-сервисов SOAP или RESTful. Все схемы данных для построения обмена информацией в региональном сегменте должны использовать язык XML в качестве стандарта описания схем. Интеграционная сервисная шина должна поддерживать необходимые профили интеграции IHE. Минимально необходимые профили - XDS.b и XDS-I.b, для хранения и организации контролируемого доступа к медицинской информации по стандартам HL7 и DICOM на основе концепции OASIS (cross document sharing). Интеграционная сервисная шина должна обеспечивать публикацию сервисов информационных ресурсов (систем) в едином репозитории SOA-активов для обеспечения доступа к компонентам федеральных транзакционных систем и компонентам федеральных управленческих систем федерального уровня ЕГИСЗ, а именно: -Информационной системе ведения расписания приемов специалистов, проведения консультаций, в том числе телемедицинских, и загрузки мощностей медицинской организации, а также электронной записи на прием к врачу; -Информационной системе выдачи направлений на проведение диагностических исследований, проведение медицинского обследования (консультации, экспертизы) и получение медицинской помощи в иных медицинских организациях; -Информационной системе бухгалтерского и управленческого учета административнохозяйственной и финансово-хозяйственной деятельности медицинских организаций; -Информационной системе кадрового учета в медицинских организациях. -Регистром паспортов медицинских организаций (при необходимости); -Регистром медицинского оборудования и медицинской техники (при необходимости); -Регистром врачей и медицинского персонала (при необходимости); -Информационной системой мониторинга реализации программ в здравоохранении (при необходимости); -Информационной системой ведения интегрированной электронной медицинской карты, а также создаваемых на ее основе специализированных регистров по отдельным нозологиям и категориям граждан, в том числе обеспечивающая персонифицированный учет медицинской помощи и лекарственного обеспечения; -Аналитическими системами, в том числе с системой автоматизированного контроля и поддержки принятия управленческих решений. Интеграционная сервисная шина должна обеспечивать стандартизацию и унификацию форматов представления данных и информационных сообщений; Интеграционная сервисная шина должна обеспечивать передачу данных всем необходимым участникам информационного взаимодействия - «потребителям информации», преобразование форматов, гарантированную доставку сообщений. Интеграционная сервисная шина должна обеспечивать целостность и сохранность информации, передаваемой и получаемой в процессе работы интеграционных сервисов. В состав интеграционной сервисной шины должны быть включены: -Службы процессов; -Средства для управления бизнес процессами, начиная от линейных, структурированных процессов и заканчивая процессами коллективной работы и неформализованными процессами, а также любыми их комбинациями; -Службы содержания; -Средства для управления жизненным циклом содержания от его создания, редактирования и повторного просмотра, до публикации и распространения; -Службы хранения; -Средства для обеспечения хранения, безопасности и архивирования содержания, а также предоставлять механизмы миграции содержания между системами хранения данных на основе жизненных циклов и процессов; -Службы интеграции; -Средства для управления содержанием, шлюзы, коннекторы, технологические адаптеры и адаптеры к бизнес-системам обеспечивающие взаимодействие с приложениями в том формате, который для них приемлем, представляя информацию из этих сообщений в унифицированном формате; -Инструменты администрирования и разработки; -Среда разработки интеграционных сценариев с визуальными средствами конструирования интеграционных сценариев, позволяющих обходиться без низкоуровневого кодирования, инструменты администрирования, контроля и управления (аудиты, протоколирование, состояние сервисов и процесса их работы, контроль соблюдения соглашения об уровне услуг, шифрование и т.д.). 3.1.3.Требования к Регистру и Репозиториям регионального уровня. Регистр и репозитории должны быть созданы для агрегирования медицинской информации о пациентах и хранения медицинских документов в различных стандартах (HL7 v2 и v3, DICOM), в том числе оцифрованных бумажных медицинских карт и историй болезни. Платформа должна обеспечивать контролируемый доступ к репозиториям не менее 1600 медицинских работников Брянской области. Регистр должен содержать всю необходимую мета-инфрмацию о документах регистрируемых и хранимых в соответствующих репозиториях, чтобы обеспечивать контролируемый доступ и поиск информации. Регистр должен отвечать техническим рекомендациям IHE по имплементации профиля интеграции XDS.b и XDS-I.b. Репозиторий должен обеспечивать и гарантировать юридическую значимость целостность, неизменность и неизменяемость документов. Все дополнения, корректировки и удаления должны соответствующим образом логгироваться и аудироваться согласно профилю интеграции XDS. Платформа должна обеспечивать создание XDS-регистра и XDS-репозитория централизованного хранилища медицинской информации Брянской области с объемом хранимой информации не менее 12 миллионов документов в год. Платформа должна обеспечивать поддержку функционирования регионального архива медицинских изображений с образованием хранения DICOM-исследований, например, рентгеновских снимков, КТ, МРТ, УЗИ и т.п., поступающих от диагностического оборудования МО Брянской области. Медицинские изображения, поступающие с диагностического оборудования и PACS, и передаваемые в центральное хранилище в формате DICOM, должны очищаться от проприетарных DICOM-тэгов, создаваемых производителями оборудования, и становиться доступными для всех МО Брянской области, как для клинических, так и для диагностических нужд. Платформа должна обеспечить нагрузку по записи, хранению и обеспечению доступа к не менее чем 1,5 млн диагностических изображений в год с объемами прироста информации не менее 100Тб/год, что должно быть подтверждено соответствующими нагрузочными тестами. Медицинские изображения, содержащиеся в региональном архиве должны храниться в оригинальном или сжатом качестве без потери информации. В случае изменения требований Министерства Здравоохранения РФ к хранению диагностических изображений, система должна автоматически конвертировать изображения в наиболее оптимальный формат для снижения стоимости хранения. Репозиторий хранения медицинских изображений должен быть независим от систем хранения данных и позволять работать с продуктами большинства производителей промышленных СХД. Доступ к документам в репозиториях должен осуществляться на основе регламентов и прав доступа, определенных законодательством РФ. 3.1.4. Требования к визуальным обозревателям. Платформа должна предоставлять рабочее место врачу-диагносту. Доступ к изображениям в репозитории медицинских изображений для клинического изучения должен осуществляться с помощью специализированного тонкого (не требующего установки дополнительного ПО на компьютер пользователя) DICOM клиента через веб-интерфейс. DICOM клиент также должен предоставлять веб-доступ к изображениям для диагностических целей в случае, если требуется удаленная диагностика. Система должна представлять контролируемый доступ медицинским работникам к медицинским документам находящихся в репозиториях через веб-портал с помощью специализированного XDS-клиента. 3.2.Требования к подсистеме формирования и ведения единой интегрированной электронной медицинской карты жителя Брянской области. Данная подсистема должна представлять хранилище данных электронных амбулаторных карт и электронных историй болезни пациентов (жителей) Брянской области. В частности, необходимо предусмотреть следующий функционал: -ведение документации врачебных осмотров, включая первичный осмотр, эпикризы, дневниковые записи; -регистрация диагнозов пациента; -регистрация врачебных назначений пациенту (консультаций, лабораторных, инструментальных, рентгенологических исследований, амбулаторных операций, процедур, медикаментозных назначений и прочего) и их результатов; -планирование и учет результатов оперативных вмешательств, включая подготовку предоперационного эпикриза и протокола операции; -формирование направлений на врачебную комиссию для проведения различных видов экспертиз и регистрация их результатов; -формирование направлений на получение медицинской помощи в иных учреждениях здравоохранения, включая направления на госпитализацию; -учет случаев обращений пациента, включая регистрацию фактов открытия, закрытия случая и результата обращения, оказанных услуг. 3.3.Требования к подсистеме «Единая электронная регистратура Брянской области». Подсистема «Электронная Регистратура» должна обеспечивать: -регистрацию пациента; -запись пациента на приём; -фиксирование осмотров, исследований, выполнения процедур; -эффективное взаимодействие персонала МО и прозрачность его работы для руководства; -формирование необходимых отчётов по статистическим данным, по пациентам, врачам и МО в целом. С помощью подсистемы автоматизируются следующие функции: -учёт обслуживаемых пациентов, что включает регистрацию обслуживаемого населения, идентификацию по регистру застрахованных граждан, по реквизитам универсальной электронной карты (УЭК), прикрепление к поликлиническим участкам обслуживания; -управление расписанием и записью на обслуживание в МО, оказывающих первичную медико-санитарную помощь, что включает в себя планирование и обеспечение ресурсов приёма пациентов участковыми врачами, врачами-специалистами, лечебно-диагностическим службами; -управление оказанием первичной медико-санитарной помощи, что включает учёт фактов оказания помощи и профилактических мероприятий участковыми врачами и специалистами, при дополнительной диспансеризации, мероприятиях в центрах здоровья. При работе с данной подсистемой необходимо учитывать возможность: -выбора типа посещения. Подсистема должен предоставлять возможность записаться на консультацию к врачу, на исследование, вызвать врача на дом; -выбора МО. В процессе записи пользователь должен имеет возможность выбрать МО, (в т.ч. воспользовавшись картой города); -выбора типа приёма. Необходимо обеспечить возможность выбора типа приёма. Тип приёма может быть платным или по полису обязательного медицинского страхования (ОМС); -выбора даты и времени. Необходимо предоставлять возможность пользователю выбирать из расписания удобное для себя, не занятое время; Процесс идентификации пациента: а) при бесплатном приеме (по ОМС) должен осуществляться поиск пациента в единой базе данных по согласованному с Заказчиком набору параметров пациента, либо по реквизитам универсальной электронной карты (УЭК), происходить сверка данных с информацией, консолидированной ТФОМС Брянской области и проверка возможности оказания требуемой услуги. б) при платном приеме необходимо позволять регистрировать пациента по ФИО и номеру телефона (опционально). Процесс подтверждения записи на приём. Необходимо обеспечить в автоматическом режиме информирование пациента о подтверждении записи на приём по e-mail и (или) SMS; Проверки полиса ОМС. Необходимо обеспечивать прием и регламентное обновление реестра застрахованных пациентов (опционально базу недействующих полисов), а также обеспечивать возможность on-line проверки полиса по базам данных ТФОМС Брянской области. При реализации подсистемы необходимо обеспечить: -ведение справочника услуг. Каждая услуга должна иметь норматив и ограничения. Норматив – это время оказания данной услуги по умолчанию. При формировании расписания должна быть возможность явного задания времени оказания услуги. -наложение ограничения на услуги по половому и возрастному признаку. Необходимо иметь возможность ведения базы данных всех сотрудников учреждений здравоохранения, в том числе ведения индивидуального портфолио для каждого сотрудника. В подсистеме должна быть реализована возможность ведения базы данных пациентов лечебного учреждения. Должна быть реализована возможность ведения индивидуального портфолио для каждого пациента. Каждое портфолио должно содержать следующую минимальную информацию: -Общие сведения; -Сведения о регистрации; -Данные о полисах ОМС. В рамках использования подсистемы необходимо: формировать структуру отделений и кабинетов МО. Структура отделений и кабинетов МО должна представлять собой иерархический справочник, в котором прописывается структура МО: филиалы, отделения, кабинеты; указывать какие услуги оказываются на рабочих местах в кабинетах. В рамках использования подсистемы необходимо предусмотреть возможность формировать графики для рабочих мест. Необходимо разбивать время приёма врача на несколько интервалов, в частности некоторые интервалы могут быть доступны для записи только для сотрудников регистратуры и врачей, другие могут быть использованы также для удалённой самостоятельной записи пациентов и т.д. Должна поддерживаться возможность формирования графиков работ с помощью заранее настроенных шаблонов: -по дням недели; -по дням месяца; -по чётности чисел; произвольные графики; С учетом выходных и праздничных дней, работы с различными режимами работы: 5-,7дневная рабочая неделя. Для осуществления записи необходимо предусмотреть следующие возможности: -просматривать расписание врачей, услуг; -записывать пациентов на приём к врачу; -осуществлять перезапись пациентов, в том числе и массовую; -взаимодействовать с порталом «Здравоохранение Брянской области». Единые справочники подсистемы должен предоставлять возможность использования единых нормативных справочников, с возможностью загрузки и обновления информации, в том числе: -МКБ; -ФИАС (КЛАДР); -Документы, удостоверяющие личность; -Социальные статусы; -Категории льгот; -Виды посещения; -Страховые компании; -Должности медицинских работников; -Специальности медицинских работников. 3.4. Требования к подсистеме «Единая электронная регистратура Брянской области для записи на прием с помощью Инфомата.» Функциональные возможности электронного сервиса, предоставляемого гражданам: -выбор типа посещения. Сервис должен предоставлять возможность записаться на консультацию к врачу, на исследование, вызвать врача на дом; выбор МО. В процессе записи пользователь должен имеет возможность выбрать ЛПУ; -выбор типа приёма. Сервис должен обеспечивать возможность выбора типа приёма. Тип приёма может быть платным или полису обязательного медицинского страхования; -выбора даты и времени. Сервис должен предоставлять возможность пользователю выбирать из расписания удобное для себя, не занятое время; идентификации пациента: а) при бесплатном приеме (по ОМС) сервис осуществляет поиск пациента в единой базе данных по согласованным с Заказчиком параметрам, либо по реквизитам УЭК, сверяет данные с информацией, консолидированной ТФОМС Брянской области, проверяет возможность оказании требуемой услуги. Сервис должен позволять принимать заявку пациента на прием к врачу сформированную по ФИО, номеру паспорта, номеру полиса ОМС, адресу регистрации, реквизитам УЭК. б) при платном приеме Система должна позволять регистрировать пациента по ФИО и номеру телефона (опционально). -подтверждать запись на приём. Сервис в автоматическом режиме должен осуществлять информирование пациента о подтверждении записи на приём по e-mail и SMS; -проверять полис ОМС. Сервис должен обеспечивать приемку и регламентное обновление реестра застрахованных пациентов (опционально базу недействующих полисов), а также обеспечивать возможность on-line проверки полиса по базам данных ТФОМС Брянской области; -иметь возможность распечатать талон записи на прием, сформированный по результатам записи. 3.5. Требования к подсистеме автоматизации учета оказанной медико-санитарной помощи ( далее – «Поликлиника»). Подсистема Поликлиника предназначена для объединения в единую информационную среду административные и лечебно-диагностические процессы, получения оперативной и достоверной информации о всех фактах оказания медико-санитарной помощи, вести интегрированные электронные медицинские карты пациентов, оптимизировать работу поликлинических отделений и формировать статистическую и аналитическую отчетность (Приложение №1). Данная подсистема включает в себя следующие модули и сервисы с наборами автоматизируемых функций: 3.5.1.Подсистема «Расписание Поликлиники». Должна автоматизировать: -создание графиков работы, как в виде шаблонов графиков, так и индивидуальных графиков. В каждом графике указывается время оказания услуги (интервал приема), количество принимаемых пациентов в один интервал, плановое количество принимаемых пациентов в день; -настройку зависимостей графиков работы от видов оплаты и типов приёма пациентов; -настройку времени работы в соответствии с типом интервала приема; -привязку расписаний работы к сотрудникам и кабинетам, услугам, диагностическим аппаратам; -назначение рабочих кабинетов врачам; -назначение перечней услуг, которые имеет право оказывать каждый медицинский работник; -назначение персоналу возможности срочного приёма пациентов; -ведение журнала работы врача; 3.5.2. Подсистема «Регистратура». Должна автоматизировать: -просмотр и редактирование данных раздела ИЭМК пациента в реальном времени; -добавление новой ИЭМК пациента и внесение изменений в существующие, при помощи справочников и ниспадающих списков. Занесение необходимых для ведения ИМЭК данных; -поиск ИЭМК пациента с использованием параметров поиска; -занесение и проверка данных в ИЭМК льготной категории пациента, инвалидности, региональной льготы, федеральной льготы; -занесение сигнальной информации в ИМЭК; -проверка актуальности полиса, указанного в ИЭМК, через сервисы, предоставляемые страховыми медицинскими организациями (СМО) и (или) ТФОМС Брянской области; -запись пациентов на приём или услугу; -заполнение данных внешнего направления, при условии что пациент направлен из другой МО; -просмотр расписания приема; -выбор удобного для пациента и свободного у врача времени приема, при необходимости пациент может быть перезаписан на другое время. -оформление талона амбулаторного пациента; -печать титульного листа амбулаторной карты пациента со всеми данными, введёнными медицинским работником. -печать договора (контракта) и информационного согласия с автоматически заполненным видом обследования, данными пациента и т.д. (используется для пациентов, оплачивающих услуги за счёт личных средств). -перезапись пациента на другое время или другого врача (замещение сотрудников); -формирование списков, журналов, отчетов по деятельности регистратуры. 3.5.4.Подсистема «Врачебный амбулаторный прием». Должна автоматизировать: -просмотр дневника врача (плана приема на день); -просмотр структурированной информации по истории заболеваний и исследований пациента, в том числе в динамике; -предоставление доступа к специализированным словарям, в которые врач самостоятельно сможет заносить данные для дальнейшего использования в работе; -ввод данных о жалобах, анамнезе и объективном статусе в ИЭМК, которые заполняются с помощью прикреплённых словарей; -просмотр сигнальной информации ИЭМК, которая содержит, в том числе данные об аллергических заболеваниях пациента, так же корректировать ее; -выдачу направлений на исследования и дополнительные врачебные консультации других специалистов; -запись на повторный прием, исследования и консультации других специалистов, непосредственно в расписание необходимого врача или кабинета, без возвращения пациента для записи в регистратуру; -занесение в ИЭМК данных о поставленном диагнозе, рекомендациях и назначенном лечении; -формирование выписки из ИЭМК и заключения по проведённому посещению; -формирование извещения и протокола запущенности; -запись на госпитализацию; -формирование направлений на обязательные для госпитализации анализы; 3.5.5. Подсистема «Больничные листы». Должна автоматизировать: -выставление отметок о принятии пустых бланков листов нетрудоспособности; -передача пустых бланков в журналы больничных листов; -управление пользователями подсистемы и уровнем их доступа к данным и функциям подсистемы; -привязка к одному журналу больничных листов нескольких пользователей для выдачи бланков из этого журнала; -ведение поиска по ИЭМК пациентов с больничными листами с помощью фильтров; -добавление отметок в ИЭМК о выдаче больничных листов для новых пациентов; -формирование больничного листа в электронном виде; -печать сформированного больничного листа на бланке строгой отчетности; -ведение журнала учета бланков строгой отчетности; -выдача дополнительных документов (продолжение больничного листа, выдача больничного листа по совместительству); -внесение информации о больничном листе в ИЭМК, выданном в другом МО; 3.5.6. Подсистема «Процедурные (физиотерапевтические, электрофизиологические и т. д.) кабинеты». Должна автоматизировать: -просмотр списка пациентов записанных на процедуры – на любой день; -внесение в ИЭМК даты следующих сеансов лечения; -внесение в ИЭМК данных о проведенном сеансе лечения (отметки о посещении); -формирование из ИЭМК выписки о проведенном курсе лечения. 3.5.7. Подсистема «Диагностические обследования». Должна автоматизировать: -просмотр направлений на диагностические исследования, указанны в ИЭМК; -просмотр из ИЭМК всей необходимой информации по истории болезни пациента. -ведение журнала учёта исследований; -внесение в ИЭМК данных о результатах исследований с использованием шаблонов; -контроль вводимых показателей на соответствие референсным значениям; -получение результатов диагностических исследований с аппаратуры (при наличии технической возможности); -прикрепление к ИЭМК графических изображений с аппаратуры (при наличии технической возможности); -контроль проведённых услуг диагностической линией по любому временному отрезку и в разрезе услуг, персонала, кабинетов, в которых они проводились; -pапись на повторное диагностическое исследование c отражением в ИЭМК; -формирование отчётов о проведённых диагностических исследованиях и работе кабинета. 3.5.8. АРМ «Заведующий (Главный врач)». Должен автоматизировать: -мониторинг работы персонала МО; -мониторинг загруженности врачей; -мониторинг оказания услуг; -просмотр аналитических отчетов. 3.5.9. АРМ «Заведующий диагностикой». Должен автоматизировать: -контроль проведённых услуг диагностических подразделений по любому временному отрезку в разрезе услуг, персонала, кабинетов, в которых они проводились; -контроль качества оказанных услуг пациентам – просмотр результатов каждого исследования; -создание и настройка графиков работы персонала. -контроль оплаты диагностических услуг – просмотр работы кассы. -формирование отчётов о работе диагностических подразделений. 3.5.10. Подсистема «Финансовые расчеты». Должна автоматизировать: -просмотр всех записей на приём и (или) госпитализацию по дням с указанием цены медицинской услуги; -проставление отметки об оплате медицинских услуг; -оформление возврата оплаченных средств; -просмотр данных лицевого счета пациента, для анализа задолженности по оказанным медицинским услугам; -просмотр и редактирование журнала платежей; -печать квитанции об оплате медицинских услуг; -просмотр и печать отчётов о количестве оплаченных медицинских услуг; -формирование и печать счетов-реестров по оказанным в МО медицинским услугам для представления на оплату в СМО; -просмотр ошибок выявленных при формировании счетов-реестров и их корректировка. Все операции по изменению финансовых данных, производимые в данной подсистеме должны отражаться в системе автоматизации административно-хозяйственной деятельности МО. Все данные о стоимости оказанных медицинских услуг должны отражаться в ИЭМК пациентов. 3.5.11. АРМ «Администратор». Должен автоматизировать: -заведение пользователей, формирование их логина и пароля доступа к информационным ресурсам; -назначение и создание ролей пользователей; -формирование и настройка словарей; -изменение интерфейсов пользователей. -настройка и разработка отчётных форм; -восстановление данных и программного кода с резервных копий при сбоях оборудования; 3.5.12. Подсистема «Статистика». Должна автоматизировать: -учет талонов амбулаторного пациента с занесение данных с заполненных в ручном режиме талонов (при необходимости); -формирование и печать статистических отчётов произвольной формы по заданным полям ИЭМК, в том числе отчетов, приведенных в Приложении №1; -просмотр и анализ сформированных отчётов с выгрузкой в согласованные с Заказчиком форматы. 3.6. Требования к программному комплексу «Формирование, хранение и обработка медицинских изображений». Программный комплекс должен обеспечивать получение диагностических изображений и соответствующих данных пациентов и исследований с диагностического оборудования различных типов по протоколу DICOM версии 3.0 и 3.1, а также их дальнейшее архивирование, обработку и передачу. Поставляемое программное обеспечение не должно иметь ограничений по количеству подключаемого диагностического оборудования, по количеству проводимых обследований, а также по объему дискового пространства, занятого базой данных по диагностическим исследованиям. Кроме того , должна быть обеспечена поддержка нескольких пространств данных. 3.6.1. Общие требования к программному комплексу. Технические требования. Комплекс должен обеспечивать: -возможность интеграции с внешними информационными системами в соответствии с международным протоколом HL7 и рекомендациями IHE (автоматизированное получение, синхронизация и корректировка данных пациентов и исследований, получение от системы RIS / HIS рабочего списка исследований и его передача на диагностическое оборудование), в том числе, с возможностью вызова диагностических изображений, хранящихся в системе PACS, непосредственно из существующих информационных систем по URL-ссылке; -доступ ко всем изображениям, хранящимся в комплексе из любого подключенного к нему учреждения, с любой рабочей станции в рамках комплекса с сохранением индивидуальных пользовательских настроек; -получение и передачу цифровых медицинских изображений по сетевому интерфейсу в стандарте DICOM 3.0 и DICOM 3.1 (DICOMStorageSCP, DICOMStorageCommitmentSCP, DICOMModalityworklistSCP, DICOMQuery/RetrieveSCU/SCP, DICOMPerformedProcedureStepsSCP), протоколсоответствия DICOM 3.0 и DICOM 3.1– DICOM conformance statement; -поддержку изображений следующих типов диагностического оборудования: CT (компьютерная томография), MR (магниторезонансная томография), CR и DR (цифровая рентгенография), US (ультразвук), XA (Цифровая ангиография), MG (цифровая маммография); -поддержку изображений в формате DICOM, полученных с помощью инструментов постобработки на специализированных рабочих станциях (secondarycapture, multiframetruecolorsecondarycaptureimagestorage, multi-framegrayscalebitesecondarycapture, multiframegrayscalewordsecondarycapture); -наличие средств для автоматизированного создания резервных копий данных с целью восстановления всех данных после сбоя вплоть до момента возникновения сбоя; -поддержку 32-разрядных и 64-разрядных процессоров; -поддержку работу как на Windows, так и на Linux–платформах; -возможности доступа к базам данных приложений, разработанных на различных платформах, поддержку языка макроопределений, получение данных из баз данных непосредственно в электронных таблицах MicrosoftExcel или аналогичных им; -возможность развертывания рабочих мест пользователей любого типа по сети силами системных администраторов; -предоставление неограниченного объема лицензий на браузер для клинического диагностирования со стандартным функционалом; -возможность выбора и сортировки по модальностям, дате обследования, отсылающим отделениям; -поддержку работы в формате не-DICOM коммуникации в целях ускорения коммуникации с сервером; -сортировку обследований для отсылки информации на конкретные рабочие места, как в пределах МО, так и за его пределами; -поддержку функций изображения видеозаписей /видео петель, таких как УЗИ, ангиография, лапароскопия и др.; -централизованное администрирование и возможность централизованной установки; -безопасный удаленный доступ для внешних сотрудничающих врачей. Эти врачи должны иметь доступ только к тем данным пациентов, которые они запрашивали; -возможность интеграции комплекса с вьюверами (просмотровыми и диагностическими станциями) других (не обозначенных в настоящем техническом задании) производителей; -возможность автоматизированной синхронизации данных, и перехода на резервное хранилище, в случае выхода из строя основного хранилища; -поддержка функционала "кластеризации" с возможностью балансировки нагрузки и переводом нагрузки с одного сервера на второй в случае выхода его из строя. Предлагаемое решение должно учитывать возможное расширение системы; -сервис по непрерывному удаленному мониторингу всей системы в формате 24x7 с обратной связью для диагностики проблемы; Для обеспечения информационной безопасности в комплекса необходима возможность шифрования трафика персональных данных между сервером и клиентами: протокол HTTPS, использование сертификатов SSL (SSL сертификаты предоставляются Заказчиком) или VPN. Кроме того необходимо наличие инструментов настройки предварительной загрузки данных исследований из архива для ускорения доступа с помощью рабочей станции в режиме „prefetching“ и „pre-pushing“; Для обеспечения надежного хранения диагностических данных, должна быть предусмотрена функция автоматического перенаправления получаемых изображений в другой DICOM архив (forwarding); Для создания административных отчётов о поступающих в комплекс данных должны быть поставлены инструменты, с учетом выполнения работ по экспорту административных отчетов и списка кодов процедур, описания процедуры и названия диагностического аппарата во внешние файлы формата Exсel (или аналог), а так же текстовый файл. 3.6.2. Общие и функциональные требования к программному комплексу. Требования к функциональным характеристикам поставляемого программного комплекса: -техническая документация и руководство пользователя должны быть представлены на русском языке; -необходимо наличие инструментов для оптимизации потока данных, прогрессивной технологии администрации обширных архивов (виртуализация), бесперебойной обработки объёмных обследований (например, 3D реконструкция, видеосеквенции и т.д.); -система должна быть модульной - для обеспечения возможности без какой-либо остановки работы бесперебойно расширяться по мере возрастания требований пользователей; - программный комплекс должен иметь следующую функциональность: -возможность хранения результатов диагностических исследований; -возможность идентификации поступающих результатов исследований в соответствии с регистром пациентов и сохранение их в хранилище ИЭМК пациентов; -возможность предоставления доступа к результатам исследований в соответствии с назначенными пользователю правами; -возможность проведения удалённых консультаций по результатам проведённых исследований; -возможность передачи данных о запланированных исследованиях непосредственно на консоли диагностических аппаратов; -возможность обеспечения в случае необходимости транслитерации данных, передаваемых на консоль диагностического аппарата; -обеспечение просмотра изображений с поддержкой следующих возможностей: -перемещение, изменение масштаба изображения; -изменение яркости и контраста изображения, а также установка стандартных для КТ «оптических окон»; -измерение линейных и угловых величин, а также площади и плотности по шкале Хаунсфилда (HU); -инверсия изображения, изменение/применение палитры; -просмотр DICOM файлов, содержащих кино петли с различной скоростью; -просмотр DICOM файлов, содержащих видео в формате MPEG-2; -просмотр DICOM файлов, содержащих инкапсулированный PDF-объект; -печать серий изображений; -печать отдельных изображений; -запись исследований на лазерные носители; -сохранение исследований на жесткий диск/flash-накопители; -экспорт исследований в виде структурированного каталога с возможностью просмотра через html-страницы; -история просмотра исследований; -загрузка серий изображений в рабочее поле в отдельном потоке с отображением процента загрузки и возможностью отмены; -отображение состояния изображения (загружено, загружается, закешировано, не загружено); -постановка загрузки серии в очередь загрузок с возможностью удаления из неё. -возможность поиска и просмотра пациентов и их исследований на основе данных ИЭМК пациента; -возможность планирования и проведения диагностического исследования. 3.6.3. Требования к программному обеспечению АРМ «Врач –диагност». АРМ «Врач-диагност» должен иметь сертификат «Программное обеспечение для медицинской диагностики в устройстве класса IIb». Должен обеспечивать: -наличие русской и английской версий с возможностью определить при установке ПО; -прогрессивная администрация прав доступа в приложение; -обеспечение аутентичности подписи врача; -совместимость с цифровым архивом и другими DICOM рабочими станциями; -поддержку служб DICOM: Query Retrive, Send; -запись результатов обследований на CD/DVD диск, включая браузер; -печать на DICOM и ПК принтерах, выбор планировки распечатываемой страницы, печать снимков и результатов обследования; -сортировку обследований в зависимости от требований запрашивающего отделения в целях визитов; -сортировка обследований для отсылки на конкретные рабочие места в пределах внедряемой централизованной системы; -возможность выбора и сортировки по модальностям, дате обследования, отсылающим отделениям; -возможность установления приоритетов обследований; -предварительной настройки комбинации вопросов к обследованию; - импорт не-DICOM данных (например, JPEG) и перевод на DICOM данные; -экспорт данных в DICOM и не-DICOM форматах (JPEG, bmp, avi); -модификацию данных в рабочей станции (слияние, разделение, ...); -исключение ошибочно включённых серий из обследования; -работу со снимками – изменение яркости, контраста, увеличение изображения, вырез, ротация изображения, измерение длины, плотности, площади, угла; -комплексную поддержку цифровой субтракции (подавление фона); -мультипланарную реконструкцию; -проигрывание циклов изображений из ультразвука, ангиографии, лапароскопии, и т.д., выбор части секвенции и её сохранение; -создание специальной серии при описании обследования с выбранными снимками; -вписывание аннотаций в снимок и его последующее сохранение; -описание обследования и его сохранение со снимками; -предотвращение дублированных описаний на двух станциях одновременно; - синхронизацию циклов (например, ангиография и ультразвук); - возможность получения изображений (принятие снимков или видео секвенций) из модальностей, оснащённых видео-выходом, и их перевод в цифровой формат DICOM 3.0); -внесение данных исследуемого пациента вручную, или их получение с помощью функции DICOM ModalityWorklist. С заданным пациентом потом сопрягаются оцифрованные данные обследования – снимки и видео секвенции. 3.6.4. Подсистема консультаций. Подсистема должна обеспечивать возможность консультаций между специалистами МО и консультативными центрами. Кроме того, подсистема должна обеспечивать: -формирование заявок на консультации; -закрепление консультанта за 1 и более МО; -учет проведенных консультаций; -оповещение консультанта (E-mail, SMS, телефонная связь) о поступлении заявки на консультацию и ее статусе (например, экстренная консультация); -регистрацию изменений в ранее проведенной консультации. 3.6.5. Подсистема ургентной телемедицины. Подсистема должен обеспечивать обработку и сохранение в центральном архиве медицинских изображение (ЦАМИ) данных, передаваемых с удаленных на расстоянии диагностических приборов. При наличии соответствующей опции используемого оборудования, подсистема должна иметь возможность вывода полученных данных на печать. Кроме того, подсистема должна обеспечивать: -оцифровку данных полученных с оборудования реализующего функции приема диагностических данных от отдаленных МО, бригад скорой и неотложной помощи; -передачу данных в оцифрованном виде в ЦАМИ с сохранением ссылки на исследование в ИЭМК пациента, а так же сохранение ургентного исследования в локальном архиве. 3.6.6. Подсистема динамической телемедицины. Подсистема предназначена для регистрации данных, полученных с оборудования наблюдения за пациентами. Подсистема должна обеспечивать функции: -оцифровки данных, полученных с оборудования, реализующего функции приема диагностических данных от удаленных систем мониторинга состояния пациентов; -передачу данных в оцифрованном виде в ЦАМИ с сохранением ссылки на исследование в ИЭМК пациента, а так же сохранение результатов мониторинга в локальном архиве. При наличии соответствующей опции используемого оборудования, должна иметься возможность вывода полученных данных на печать. 4. Требования к работам, выполняемым в рамках настоящего технического задания. В рамках настоящего технического задания должны быть выполнения нижеследующие работы: 4.1. Общий перечень работ. 4.1.1.Разработка и согласование с Заказчиком регламента информационного взаимодействия РИС ЭМ Брянской области с реестрами и репозиториями регионального уровня. 4.1.2.Обеспечить реализацию и размещение на Платформе «интеграционная шина» следующих интеграционных сервисов: -сервиса доступа к каталогу пользователей ЕГИСЗ, создаваемого на федеральном уровне ЕГИСЗ; -сервиса доступа к подсистеме нормативно-справочной информации и словарям медицинских терминологий, создаваемой на федеральном уровне ЕГИСЗ; -сервиса взаимодействия с системой межведомственного электронного взаимодействия, единым порталом государственных и муниципальных услуг, региональным порталом государственных и муниципальных услуг (при необходимости), создаваемыми в рамках инфраструктуры электронного правительства; -сервиса взаимодействия с информационными системами страховых медицинских организаций (СМО) и унаследованными медицинскими информационными системами, внедренными в МО Брянской области (при их соответствии функциональным требованиям, представленным в п.3 настоящего технического задания); -сервиса нормализации данных (обеспечение вендеронезависимости) собираемых из МО Брянской области, включающий в себя очищение DICOM и HL7 сообщений, а также согласование и применение федеральной и региональной НСИ; 4.1.3.Провести опытную эксплуатацию по интеграции РИС ЭМ Брянской области со следующими первоочередными (базовыми) федеральными сервисами (по мере их ввода в эксплуатацию): -базовый федеральный сервис интегрированной электронной медицинской карты и сервисов доступа к ней с использованием сервисно-ориентированных и облачных технологий по профилям интеграции IHE XDS.b, входящей в состав Единой государственной информационной системы в сфере здравоохранения Министерства здравоохранения Российской Федерации (сервис ИЭМК); -базовый федеральный сервис управленческого учета административно-хозяйственной деятельности медицинских организаций, в том числе автоматизирующей функции взаимодействия со страховыми медицинскими организациями в части формирования и оплаты счетов за оказанную медицинскую помощь, и управленческий кадровый учет в медицинских организациях, на основе существующих федеральных управленческих систем с использованием облачных технологий (сервис АХД); -базовый федеральный сервис ведения расписания приемов специалистов, проведения консультаций, в том числе телемедицинских, и загрузки мощностей медицинской организации, а также электронной записи на прием к врачу, с учетом возможности интеграции с внешними информационными системами с использованием облачных технологий (сервис Регистратура); -базовый федеральный сервис информационно-аналитической системы Министерства здравоохранения РФ в части поддержки принятия управленческих решений на основе данных мониторинга, регистровых данных и данных первичного учета в здравоохранении (сервис ЕАС). 4.1.4.Разработка и согласование с Заказчиком программы и методики испытаний средств интеграции обеспечивающих доступ к компонентам федерального уровня, компонентам электронного правительства Брянской области, информационным ресурсам МО Брянской области, департамента здравоохранения Брянской области, в том числе к РИС ЭМ и унаследованным МИС. 4.1.5.Проведение приемочного тестирования средств интеграции обеспечивающих доступ к компонентам федерального уровня, компонентам электронного правительства Брянской области, информационным ресурсам МО Брянской области, департамента здравоохранения Брянской области, в том числе к РИС ЭМ и унаследованным МИС согласно Программы и методики испытаний. 4.1.6.Выполнение работ по предпроектной стадии построения системы защиты персональных данных для МО Брянской области. 4.2. Требования к разработке регламентов информационного обмена РИС ЭМ и их документированию. Объем (содержание) выполняемых работ: 4.2.1.Определение технологических контуров информационного обмена, субъектов информационного обмена и объектов, участвующих в информационном обмене, направлений информационных потоков, состава данных, определение мастер данных, систем, где обрабатываются мастер данные, алгоритмов обработки в визуализации данных. 4.2.2.Разработка макетов интерфейсов исходя из результатов анализа и согласование с Заказчиком и Разработчиками интегрируемых информационных систем. 4.2.3.Определение периода обмена с указанием направления потоков данных, управляющих организаций, должностных лиц – потребителей информации, способов получения и доставки информации. 4.2.4.Определение порядка передачи данных, очередности, полноты и уровня агрегации. 4.2.5.Интеграция региональных справочников и классификаторов с федеральными справочниками, построение таблиц соответствия и перекодировки. 4.2.6.Подготовка комплекта документов для законодательного утверждения регламентов обмена данных, где отражены стороны, участвующие в обмене, периодичность и очередность обмена, описание потоков данных, состав, назначение, форматы данных, в которых системы получают/отдают данные, приоритет данных. Закрепление ответственности за корректное функционирование, принятия решений в спорных ситуациях, право на изменение или инициацию изменения регламентов. 4.2.7.Результатом исполнения работ по разработке регламентов информационного обмена должны быть: -карты информационного обмена; -пояснительные записки, сопровождающие карты регламентов информационного обмена и содержащие следующее: -участники (субъекты); -перечисление в виде таблицы учреждений и организаций, обменивающихся данными, с указанием их роли в информационном обмене; -объекты (информационные сущности); -описание в виде таблицы сущностей, которыми обмениваются участники, с указанием наименований, параметров, типов данных; -режим (порядок) обмена; -описание в виде таблицы условных событий и временных условий, в соответствии с которыми происходят транзакции информационного обмена; -инструменты и механизмы. Текстовое описание инструментов и протоколов с указанием номеров их версий, используемых при информационном обмене. Схема, иллюстрирующая порядок применения инструментов и протоколов; -форматы данных. Описание в виде таблицы правил именования файлов и/или сообщений, используемых при информационном обмене. Описание в виде таблицы их внутренней структуры и синтаксических конструкций, используемых при описании данных. -совместимость. Текстовое описание стандартов описания медицинской информации, совместимость с которыми обеспечивается при информационном обмене с пояснением степени соответствия. Указание ссылок на информационные источники, содержащие полные версии упоминаемых стандартов; -форс-мажорные ситуации. Описание в виде таблицы теоретически возможных исключительных ситуаций и способов их разрешения с целью восстановления нормального порядка выполнения информационного обмена. 4.2.8. Комплект проектов нормативных документов по РИС ЭМ: -закон Брянской области «Об РИС ЭМ Брянской области», определяющий правовые основы эксплуатации РИС ЭМ в Брянской области, с учетом Федеральных законов РФ, Постановлений Правительства РФ, Приказов Минздравсоцразвития России, других законов Брянской области; -постановление администрации Брянской области «О введении в действие Положения о РИС ЭМ Брянской области», обеспечивающего на основании закона Брянской области «Об РИС ЭМ Брянской области» перечень мероприятий по обеспечению функционирования РИС ЭМ Брянской области; -приказ департамента здравоохранения Брянской области «О введении в действие Положения о Регистре нормативно-справочной информации здравоохранения Брянской области»; -приказ департамента здравоохранения Брянской области «О введении в действие Положения о Регистре медицинского и фармацевтического персонала Брянской области»; -приказ департамента здравоохранения Брянской области «О введении в действие Положения о Едином регистре застрахованных граждан Брянской области»; -приказ департамента здравоохранения Брянской области «О введении в действие Положения Регистре паспортов медицинских учреждений Брянской области (включая регистр медицинской техники и изделий медицинского назначения)»; - приказ департамента здравоохранения Брянской области «О введении в действие Положения об Интегрированной электронной медицинской карте (ИЭМК) жителя Брянской области»; - приказ департамента здравоохранения Брянской области «О введении в действие Требований к МИС, эксплуатируемой в медицинских организациях Брянской области». 4.3. Требования к работам на предпроектной стадии построения системы защиты персональных данных (СЗПДн) МО Брянской области. 4.3.1. Основание для проведения работ: -Федеральный закон Российской Федерации от 27 июля 2006 г. № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; -Федеральный закон Российской Федерации от 27 июля 2006 г. № 152-ФЗ «О персональных данных»; -Постановление Правительства РФ от 17 ноября 2007 г. № 781 «Об утверждении Положения об обеспечении безопасности персональных данных при их обработке в информационных системах персональных данных»; -Постановление Правительства РФ № 687 от 15.09.2008 г. «Об утверждении положения об особенностях обработки персональных данных, осуществляемой без использования средств автоматизации»; -Приказ Гостехкомиссии России от 30 августа 2002 г. № 282 «Специальные требования и рекомендации по технической защите конфиденциальной информации (СТР-К)». -Совместный приказ ФСТЭК России, ФСБ России и Мининформсвязи России от 13 февраля 2008 г. № 55/86/20 «Об утверждении порядка проведения классификации информационных систем персональных данных»; -Приказ № 154 Федеральной службы по надзору в сфере массовых коммуникаций, связи и охраны культурного наследия от 28.04.2008 «Об утверждении Положения о ведении реестра операторов, осуществляющих обработку персональных данных»; -Приказ ФСТЭК России от 5 февраля 2010 г. № 58 «Об утверждении положения о методах и способах защиты информации в информационных персональных данных»; -Руководящий документ ФСТЭК России «Базовая модель угроз безопасности персональных данных при их обработке в информационных системах персональных данных»; -Руководящий документ ФСТЭК России «Методика определения актуальных угроз безопасности персональных данных при их обработке в информационных системах персональных данных»; -Руководящий документ Гостехкомиссии России «Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем и требования по защите информации»; -РД 50-34.698-90 «Автоматизированные системы. Требования к содержанию документов»; -ГОСТ 34.601-90 «Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания»; -ГОСТ 34.201-89 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплексность и обозначение документов при создании автоматизированных систем»; -ГОСТ 34.003-90 «Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения»; -настоящее техническое задание. 4.3.2.Назначение и цели проведения работ: -выполнение мероприятий по созданию СЗПДн; -обеспечение защищенности информационных систем персональных данных (ИСПДн) в процессе обработки и хранения ПДн, а также обеспечение конфиденциальности ПДн при их обработке; -соответствие требованиям обеспечения ИБ при обработке ПДн в ИСПДн, регламентируемых РД ФСТЭК России и ФСБ России. -идентификация ИСПДн как совокупности конкретных технических средств, технологий и обрабатываемых данных, имеющих четко обозначенный контур защиты, в котором исключено неконтролируемое пребывание посторонних лиц (контролируемую зону), и принятие решения о проектировании и создании системы защиты персональных данных для каждой идентифицированной ИСПДн; -знакомство с фактическим уровнем безопасности информации, хранящейся и обрабатываемой на объекте; -оценка степени соответствия информационных систем, в которых обрабатываются персональные данные, требованиям законодательства России в области защиты персональных данных. -подтверждением соответствия достигнутых результатов заданным целям в рамках настоящего ТЗ является Акт классификации ИСПДн и модель угроз. 4.3.3 Требования к работам: 4.3.3.1.Работы необходимо осуществить по этапам: -обследование ИСПДн и сбор исходных данных; -классификация ИСПДн; -разработка Модели угроз; 4.3.3.2.Характеристика этапов проведения работ: -получение Исполнителем от Государственного заказчика материалов, описывающих состав ПДн, топологию, технологию и порядок обработки и защиты ПДн, состав организационноштатной структуры предприятий Заказчика, принимающей участие в обработке ПДн. -представление Исполнителем проектов Актов классификации ИСПДн и модель угроз. 4.3.3.3.Состав и содержание работ: -уточняется перечень ПДн, подлежащих защите; -определяется организационно-штатная структура предприятия с привязкой к бизнеспроцессам обработки ПДн (уточняется степень участия сотрудников в обработке информации, характер их взаимодействия между собой); -уточняется информация о категориях и составе ПДн, обрабатываемых автоматизированными и неавтоматизированными способами; проводится анализ состава ПДн в ИСПДн, собирается информация о защищенности ПДн; -уточняются условия расположения объекта защиты относительно границ контролируемой зоны; -уточняются конфигурация и топология ИСПДн и систем связи в целом и их компонентов, физические, функциональные и технологические связи как внутри этих систем, так и с другими системами различного уровня и назначения; -уточняются состав технических средств и систем, предполагаемых к использованию в ИСПДн, условия их расположения, общесистемные и прикладные программные средства; -уточняются режимы обработки информации в ИСПДн в целом и в отдельных ее компонентах; -для ИСПДн производится анализ собранной информации об угрозах и их показателях для разработки Модели угроз; -уточняется класс ИСПДн; -разрабатывается Модель угроз для ИСПДн на основе РД ФСТЭК России «Базовая модель угроз безопасности персональных данных при их обработке в информационных системах персональных данных»; -разрабатывается (в случае необходимости) Модель нарушителя на основе РД ФСБ России «Методические рекомендации по обеспечению с помощью криптосредств безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств автоматизации». 4.3.4. Требования к отчетным документам. По результатам работы Заказчику предоставляются следующие документы: -отчет об обследовании ИСПДн; -проект Акта(ов) классификации ИСПДн; -модель(и) угроз ИСПДн. Классификация ИСПДн должна быть выполнена в соответствии с требованиями Приказа ФСТЭК России, ФСБ России, Мининформсвязи России №55/86/20 от 13 февраля 2008 г. «Об утверждении Порядка проведения классификации информационных систем персональных данных». Комплект отчетных материалов предоставляется Заказчику в электронном виде и на твердой копии. Вся разрабатываемая документация должна быть выполнена на русском языке. 5. Порядок сдачи и приемки РИС ЭМ Брянской области. 5.1. По результатам выполнения работ проводятся приемо-сдаточные испытания. 5.2. Приемочные испытания должны завершаться оформлением соответствующего акта с приложением протоколов испытаний. 5.3. Место проведения испытаний должно определяться Заказчиком. 5.4. Сроки проведения испытаний должны определяться Календарным планом, являющимся приложением к Государственному контракту на выполнение работ по созданию РИС ЭМ Брянской области. 5.5. Гарантийное обслуживание РИС ЭМ Брянской области должно осуществляться на условиях, определенных Государственным контрактом на выполнение работ по созданию РИС ЭМ. 5.6. В состав комиссии по проведению испытаний должны входить представители Заказчика и Подрядчика. 5.7. Состав приёмочной комиссии, место и время проведения испытаний должны задаваться распорядительным документом (приказом) Заказчика. 6. Гарантии. 6.1. Минимальный период гарантийных обязательств на качество работ (гарантийный период) составляет 12 (двенадцать) месяцев с момента подписания акта сдачи-приемки работ по настоящим требованиям. 6.2. Объем предоставления гарантии качества работ: -гарантийное обязательство должно включать бесплатное обновление версий программного обеспечения, организацию «горячей линии» для консультаций Заказчика в соответствии с таблицей 2.2. В случае наличия сбоев в работе программного обеспечения системы, в течении срока предоставления гарантии качества работ по вине Поставщика, последний обязуется устранить замечания Заказчика к функциям системы, и в восстановить ее работоспособность в соответствии со сроками, указанными в таб. 2.2. Срок полезного использования Системы – 3 года. 7. Доступность РИС ЭМ Брянской области. № п/п Наименование объекта 1. ГАУЗ «Брянская городская г. Брянск, ул. стоматологическая поликлиника № Пушкина,7 3» Адрес Единая электронная регистратура Брянской области Запись на прием к врачу при помощи сети Интернет Запись на прием к врачу через Инфомат Да Да Да Подсист ема «Поликл иника» Подси стема «Стац ионар » Подсистема формирования , хранения и обработки мед.изображе ний Да Нет Да Реестр форм отчетности ИМС ЭР: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. Формы отчетности Подсистемы «Поликлиника»: Временная нетрудоспособность по врачам поликлиники; Временная нетрудоспособность по отделениям поликлиники; Динамика осмотра диспансерных больных по поликлинике; Диспансерное наблюдение (по МКБ) по врачу; Заболеваемость по данным обращаемости населения; Количество диспансерных больных по отделению; Незаконченные случаи обслуживания; Объемы работ рентгено - флюорографического отделения; Отчет о деятельности больницы по нозологии по амбулаторным пациентам; Отчет о числе заболеваний зарегистрированных МО; Отчет по всем лабораториям; Отчет по ЛФК; Первичный выход на инвалидность; Посещения на дому по врачу; Сводные данные о деятельности поликлиники; Смертность на дому по поликлинике; Социальный контингент по району; Список зарегистрированных пациентов по врачу, поликлинике; Список льготных рецептов по пациенту; Стационарное лечение больных; Характер объема поликлинического обслуживания; Приложение к извещению о проведении запроса предложений № п/п 1 Наименование объекта Адрес ГАУЗ «Брянская городская стоматологическая поликлиника № 3» г. Брянск, ул. Пушкина,д.7 Единая электронная регистратура Брянской области Запись на прием к врачу при помощи сети Интернет Запись на прием к врачу через Инфомат Подсистема «Поликлиника » Подсистема «Стационар » Подсистема формирования, хранения и обработки мед.изображени й Да Да Да Да Нет Да
