Никому не попадались программы для ведения базы данных о пациентах (другими словами, программное обеспечение для клиник), где бы можно было вносить диагнозы, назначаемое лечение, дату повторного визита и пр.?
Или дайте ссылки на эти ресурсы (желательно бесплатные) или тематические форумы.
Заранее спасибо.

P.S.: может быть это вопрос и не для этой ветки форума, но более подходящей я не нашел

На английском языке - довольно много. На русском - во многих клиниках системы электронного ведения историй болезни (типа Медианы и других). Стоят они очень дорого. Вопрос зачем - для целей учета и оплаты лечения, просто напоминания и т.п.? В заивисмости от задачи можно найти и бесплатные, однако большая часть делается для ЛПУ в целом.

Помню, было фирменное решение от IBM. Мощное и безумно дорогое. На базе IBM AS/400.

В отечественном здравоохранении, с целью разумного расходования бюджетных средств, следовало бы в главном ВЦ разработать (или заказать) данное решение, а затем тиражировать его [хотя бы] в государственных учреждениях здравоохранения, обеспечив централизованное обновление с учетом вновь возникающих ситуаций. Мне совершенно точно известно, что именно так делают в серьезных государственных корпорациях, когда хотят эффективно использовать средства, пусть даже очень скромные и получить в конечном итоге отличную управляемую систему. В качестве основы часто используется SAP.

У нас же каждая больница, институт или областное отделение фонда обязательного медицинского страхования силами собственных или привлекаемых программистов разрабатывает оригинальные самодельные решения на основе собственных же требований. Это ведет, как правило, к неудовлетворительному качеству, отсутствию полноценной поддержки при весьма больших затратах. К тому же поддерживать весь этот "зоопарк" в работоспособном состоянии нормальной возможности нет. Нет ни возможностей для оплаты труда квалифицированных программистов, ни самих программистов. Поддержка же готовой системы программистами низкой квалификации либо даже вообще непрограммистами (хоть врачем или студентом на полставки) дала бы экономию в масштабах страны колоссальную.

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

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

Попробуй поискать на сайте http://www.therdep.alfacom.net/ Там когда-то была база для ведения терапевтических больных стационара.

Вот упомянутые решения
- от IBM: http://www.rosinvest.com/news/12472/
- от SAP: http://www.sap.com/cis/industries/healthcare/index.epx

Из отечественных
- "Умная клиника" от Московской компании "Квазар-микро" (на сайте не найдено упоминания, но рекламный буклет привезли с выставки буквально 2 дня назад) http://www.kvazar-micro.com/ru/
- Решения от Московской компании "ТОНЛАЙН": http://www.tonline.su/index1.html
- PatientBase и другие решения от ASE Group: http://www.ase.ru/
- Занимался проблемой Тюменский "Сибтел" (упоминания на сайте опять же нет, но доводилось видеть демонстрационную систему, можно связаться с разработчиками, решение очень понравилось) http://www.sibtel.ru/
- "Медико" из Екатеринбурга: http://www.tokenit.ru/token/index.php, имеется демо
- МедОфис из Екатеринбурга: http://www.medoffice.ru/

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

В-общем, множество решений на любой вкус и на любой кошелек. Возможны и заказные решения. Проблема-то не особо сложная (для профессионалов), можно использовать готовые наработки. А эффективность высокая. К примеру, приходит человек на прием в поликлинику. Врач, осмотрев пациента, назначает ему ряд анализов, причем пациенту не нужно никуда идти записываться, скажем, на рентген, томограф, УЗИ. Врач запишет его через систему нажатием нескольких клавиш. Через систему же получит результаты. Автоматически будет сформирована отчетность, выписки, счета на оплату. Аккуратная, размеренная и красивая работа без спешки. Сейчас на это уходит много времени и нервов и врача, и пациента.

Напоследок немного о стандартизации информационных систем медицинского назначения. Найдите и посмотрите документ под названием "Система стандартизации в здравоохранении Российской Федерации. Стандарт организации. Информационные системы в здравоохранении. Общие требования. СТО МОСЗ 91500.16.0002-2004 // Проблемы стандартизации в здравоохранении, 2004, № 8, с. 24-82".

Вот некоторые материалы о "самоделках":
1. Шевелев В.М., Хасаншина Е.В., Хасаншин Ю.Р. Анализ эффективности внедрения медицинской информационной системы в учреждении здравоохранения // Здравоохранение, 2003, № 2, с. 177-186.
2. Мелюк С.А., Карпов Н.Л. Информационно-аналитическая система социально-гигиенического мониторинга в Ярославской области // Информационные технологии в здравоохранении, 2003, № 1-2, с. 23-29.

И системы хорошие, и авторы - профессионалы. Но хотелось бы видеть вместо этого что-то типа "Единая информационная система здравоохранения РФ на базе SAP R/3", в обязательном порядке (= внедренную законодательно) функционирующую во всех федеральных и муниципальных учреждениях здравоохранения. Причем полученную данными учреждениями бесплатно. И бесплатные on-line курсы по данной системе. И запрещение использовать "самоделки".

Кроме указанных выше, рекомендую программу ЛИК 1.0. В ЭИБ в хронологическом порядке регистрируется весь ход лечебного процесса От момента поступления в стационар до выписки больного.
Программа автоматизации медицинского учреждения "ЛИК" представляет собой комплекс программных модулей, обеспечивающих ввод, хранение и обработку информации.
Позволяет формировать необходимую медицинскую документацию, отчеты. «ЛИК»
Позволяет автоматизировать работу многопрофильной больницы.
Программа может работать как на отдельном компьютере, так, и организована работа по локальной больничной сети.
Возможно поэтапное внедрение программы.
Для упрощения и ускорения работы по вводу информации, создана возможность заполнения, на основе созданных для каждого отделения шаблонов, с последующей их корректировкой.
Применяется вставка значений по умолчанию, заполнение данных из справочных таблиц.

Модули программы "ЛИК"
-Приемный покой
-Отделение
-Отделение УЗИ
-Лаборатория
-Дополнительные исследования (ЭКГ, рентген, компьютерная томография?.)- в стадии разработки (В данной версии имеется возможность добавления данных из рабочего места врача отделения).

Рекомендуемые системные требования:
Pentium II, Оперативная память: 128мб, Операционная система: Windows 98, Me, 2000, XP, 2003
прога бесплатная (пока)
Ссылка http://soft.protoplex.ru/soft_show/5190.html
Пользуйте. Да, при установке и использовании иногда бывают баги с MySQL, но это устранимо. Обязательно посетите сайт разработчика.
Также можно вести достаточно полноценную базу пациентов в MS Access, но на её построение нужно достаточно времени и знаний из области СУБД.

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

К списку "монстров" можно еще добавить Oracle Healthcare Applications (http://www.oracle.com/industries/healthcare/index.html).
Зная продукты Oracle, IBM и сталкиваясь с SAP, могу сказать, что с безопасностью, разграничением полномочий и т.д. там все в порядке. Правда, насколько упомянутый госстандарт "продвинут" сам в этом вопросе, не знаю.

Программа http://doctorstat.narod.ru работает с БАЗОЙ ДАННЫХ пациентов в формате Access. В базу данных уже включены основные характеристики больного: возраст, пол, заболевание (в виде иерархического дерева), клинические параметры и т.д. Новые параметры, которых нет в базе, легко добавляются стандартными средствами Access. После заполнения базы данных она используется для разнообразного статистического анализа. С помощью базы легко делаются выборки по различным условиям: возраст, пол, заболевание и т.д. Все необходимые средства анализа и визуализации интегрированы в программу. Результаты анализа (таблицы, графики) сохраняются в формате Excel, поэтому их можно смотреть на любом компьютере, где установлен office.

Access (включая способ доступа к данным) пригоден для персонального использования либо для небольшой сети с небольшой нагрузкой. При серьезной нагрузке требуются соответствующая СУБД и ПО, расчитанное на работу с ней.

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

Если уважаемых коллег заинтересовала данная информация, могу предоставить все необходимые ссылки на информационные ресурсы (за исключением 4-х документов ФСТЭК с грифом ДСП).

Приглашаю также обсудить меры по решению проблемы.

Было бы интересно познакомиться с такими документами. У нас (Белоруссия) пока до этого дело не дошло (к сожалению). Но, думаю, вскоре также будут подвижки в этом направлении.

По существу.
Вся информация госпитальной системы хранится в БД. Рискну предположить, что для более-менее крупной системы это будет из коммерческих: MS SQL сервер, Oracle, 4D, из бесплатных: mysql, PostgreSQL.
Как мне видится, в случае MS SQL сервер, Oracle проблема хранения, регламентации доступа прозрачно решается на уровне сервера и/или сервера приложений (возможно, с приобритением дополнительных модулей). В случае с Oracle регламентация может вестить "в особо извращенном виде ". Однако, скорее всего, прийдется изменять представления (если приложение написано нормально) или править запросы, что гораздо хуже.
При использовании mysql, PostgreSQL Нужно будет шифровать поля с персональной информацией и реализовывать механизм организации доступа. Это приличные переделки в ПО.

Остается открытым вопрос передачи персональных данных по сети. В случае с Oracle есть прозрачное решение. Как в SQL server -- не знаю.

В критической статье http://bankir.ru/news/experts/lukatsky/1725793 графически представлен весь набор документов. См. также http://www.microsoft.com/Rus/Security/Cert...why_to_use.mspx.

Укажем официальные источники. Это:
1. Закон РФ №160-Ф3 и Конвенция http://www.medialaw.ru/laws/other_laws/eur...on-autodata.htm
2. Закон РФ №152-Ф3 о персональных данных http://www.rg.ru/printable/2006/07/29/pers...dannye-dok.html
3. Постановление Правительства №781 http://www.rg.ru/2007/11/21/personalnye-dannye-dok.html
4. Постановление Правительства №687 http://www.rg.ru/2008/09/24/dannye-obrabotka-dok.html
5. Приказ трех http://31.rsoc.ru/.cmsc/upload/documents/P...az_13_02_08.doc
6. Примеры уведомлений и других документов http://www.rsoc.ru/main/directions/874/
7. 4 документа ФСТЭК официально не опубликованы и доступны с ограничениями, как показано ниже
8. Документы ФСБ в данном конкретном случае не требуются, но имеются в открытом доступе (см. ниже адрес сайта)

Официальные сайты:
1. Роскомнадзор http://www.rsoc.ru
2. ФСТЭК http://www.fstec.ru
3. ФСБ http://www.fsb.ru

Теперь о сертификации программных продуктов. Компания Microsoft делает официальное признание http://www.microsoft.com/Rus/Security/Cert...ed_product.mspx, что сертифицированные продукты ничем (!) не отличаются от обычных. См. также комментарий официального лица компании http://www.compress.ru/article.aspx?id=18049&iid=838. Хотя на самом деле продукты отличаются - ценой. Вот пример http://www.altx-soft.ru/groups/page-29.htm. К тому же в процессе сертификации программ и оборудования в России есть нюанс. Если во всем мире сертифицируется серия продуктов (например, Windows XP SP3), в России - каждый экземпляр (только тот экземпляр, который вы купили).

Далее об обсуждении и мерах по оптимизации затрат организаций для исполнения рассматриваемого законодательства. На первую из данных в настоящем посте ссылку мы уже обратили внимание - законодательство принято с нарушениями законов. От себя добавим ссылку http://www.rg.ru/2009/01/21/konstitucia-dok.html на статью 15 Конституции РФ: "3. Законы подлежат официальному опубликованию. Неопубликованные законы не применяются. Любые нормативные правовые акты, затрагивающие права, свободы и обязанности человека и гражданина, не могут применяться, если они не опубликованы официально для всеобщего сведения". Официальное опубликование - это в "Российской газете", а гриф ДСП отменяет "всеобщность". Но исполнять эти акты придется. Вот тут предложены некоторые меры http://www.iksmedia.ru/blogs/post/449145.html. Хотя ряд положений еще нужно доказать.

Мы же от себя рискнем предложить одно средство, идея которого заимствована (извините) из практики ветеринарных клиник. Так, в ветеринарных клиниках применяется аналог амбулаторной карты - карточка животного. У животного - идентификатор (номер). Нет ни фамилии (Шарик?), ни адреса (Будка во дворе?), но тем не менее животных никто не путает. Так вот, идея - удалить из электронной истории болезни всю (!) персональную информацию. Номер истории болезни и штрих-код не являются персональными данными, но достаточны, чтобы безошибочно соотнести документ и субъекта в ходе клинической работы. Требования к сбору и хранению обезличенных данных существенно ниже. Согласно ст. 7 Закона 152: "2. Обеспечение конфиденциальности персональных данных не требуется: 1) в случае обезличивания персональных данных..." По данной теме см. также "ГОСТ Р 52636-2006 Электронная история болезни. Общие положения" http://webmed.irkutsk.ru/doc/pdf/gost52636.pdf.

Отмечу, что персональная информация о сотрудниках (медработниках, ином персонале), циркулирующая в отделе кадров и бухгалтерии учреждения, под действие указанных законов не подпадает согласно ст. 22, п.2, поз.1 закона №152. Поэтому, если история болезни в больнице - только на бумаге, хоть даже зарплату считают на компьютере, все сказанное тут к ней отношения не имеет.

Как уже отмечалось, затраты для исполнения законодательства о персональных данных в медицинских учреждениях будут большими. В нашей небогатой медицине таких средств просто нет. Поэтому, на наш взгляд, на сегодня единственным приемлемым решением проблемы является полный отказ от ведения электронных историй болезни с переходом (к досаде тех, кто, к сожалению, имел нетерпеливость сделать это) исключительно на бумагу. Посмотрите любопытный документ http://www.indem.ru/FSmonitor/Obsujde/PersDan/DaGoMiRe.htm (в части, касающейся данной темы, и за исключением истерики).

... сертифицированные продукты ничем (!) не отличаются от обычных ... Хотя на самом деле продукты отличаются - ценой. ... в России ... сертифицируется ... каждый экземпляр.
Строго говоря, сертифицироваться должно конкретное решение, включая использование железа. Т.е., програмно-аппаратный комплекс. Возможно, с определением в сертификате некоторых допусков по замене отдельных компонентов железа (например, замена коммутатора) и применению обновлений.
Сертификаты (до определенного уровня безопасности) есть на отдельные компоненты. Но список очень ограничен, например у Оракл есть сертификат ФСТЭК на IAMS -- http://www.oracle.com/global/ru/press/ppr/02022009.html
Вопрос в том, что будет считаться "разумным и достаточным" уровнем безопасности.

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

Мы же от себя рискнем предложить одно средство, идея которого заимствована (извините) из практики ветеринарных клиник.
Не извиняю . Я -- собачник. Так что это скорее комплимент .

...в ветеринарных клиниках применяется аналог амбулаторной карты - карточка животного. У животного - идентификатор ... Нет ни фамилии ..., ни адреса ..., но тем не менее животных никто не путает. ... идея - удалить из электронной истории болезни всю (!) персональную информацию.
Честно говоря, данная идея лично мне кажется ущербной. Сразу возникает множество вопросов идентификации пациента, связывания информации с другими данными в интересах пациента. Про проблему дублей, думаю, и так понятно. Опять таки, как быть с выписками?
Пример с животными, на мой взгляд, слишком локален что-ли. Кроме того, у животных, скорее всего, номер в карточке привязан к вживляемому микрочипу.

Как уже отмечалось, затраты для исполнения законодательства о персональных данных в медицинских учреждениях будут большими. ... на наш взгляд, на сегодня единственным приемлемым решением проблемы является полный отказ от ведения электронных историй болезни с переходом ... исключительно на бумагу. Для бумажный носителей требования также строгие, но менее затратные.
1. В зависимости от фактических требований могут быть Очень большимы. Ведь при этом не следует забывать, что при использовании таких систем автоматически возникает вопрос скрытых расходов: введение должности так называемого офицера по безопасности, сертификации персонала, управляющего системой и т.д.
2. У нас электронная запись о пациенте в БД документом не является. ДокУмент -- только на бумаге и с подписями и печатью.
3. Электронный эквивалент информации о пациенте -- это не только сама информация, но и информация более высокого уровня в консолидированном выде, т.е. разные отчеты. Вряд ли кто-либо вернется к ручному подсчету выписок и т.д., тем более, что количество отчетов и срезов, во всяком случае у нас, растет с каждым годом.
Промежуточным решением может быть использование обезличенных данных в БД с применением штрихкода для в качестве связующего звена между БД и историей болезни.

P.S. Насколько я понимаю, данная проблема коснется в полной мере и страховых компаний. Они что, не шевелятся совсем?

Стоит задача выбора из разных вариантов. Приведу пару крайних.

Вариант 1. Полная история болезни - в информационной системе. В компьютере - полный аналог бумажной истории и даже больше. Все довольны и улыбаются. Удобство и быстрота. Проблемы: конфиденциальность Г1, класс К1. Пример: http://hl7.ru/wp-content/uploads/2009/04/s..._ramn_30108.ppt. Цена (на крупную клинику): 10-20 миллионов рублей раз в 3 года (на сертифицированное ПО), аудит и проверки каждые полгода, задержка обновлений ПО (все обновления, включая антивирусы - через специальный сайт) на недели и месяцы (иначе сертификат аннулируют). При противоречивых требованиях и отсутствии внятных критериев - положительные результаты проверок не гарантированы. Вот откровение самих законодателей http://www.duma.gov.ru/csecure/public/022.doc. И подумайте, что будет с вашей информационной системой, если антивирус вы будете обновлять раз в неделю, а Виндоус - раз в месяц.

Вариант 2. Полностью бумажная история болезни. Конфиденциальность отсутствует, класс К4. Никаких мер не требуется. Цена: 0 рублей. Проверок нет, уведомления, регистрации и лицензирования по защите информации нет (в примере выше они есть - на 3 года, потом по новой).

Думаю, рассматривать нужно все-таки промежуточные варианты. Ущербная идея? Если руководство клиники согласно платить 20 млн. раз в 3 года за ваше удобство делать выписку, при этом подвергая существующую информационную систему реальной опасности (см. ниже) - ради бога. Если нет, возьмете бумажную историю, в Ворде набьете выписку (можно иметь ее шаблон, кстати), отпечатаете и выйдете без сохранения. Вот и нет проблемы.

Сноска о реальной опасности. Обратите внимание - ФСТЭКом не сертифицирован ни один аппаратный межсетевой экран, включая последние модели ведущих мировых производителей. Подчеркиваю - ни один аппаратный. Сертифицированы десяток программных самоделок местных умельцев, причем половина сертификатов просрочена. Это как раз и свидетельствует о недостаточном уровне всего проекта защиты (как бы необходимо, но недостаточно). Подключать к сетям общего пользователя свою локальную сеть, используя только программный файерволл, неразумно. У меня даже дома аппаратный экран стоит.

В книге Джона Чирилло "Обнаружение хакерских атак" утверждается, что само наличие и тип средства защиты - это уже должно быть большой тайной для хакера. У нас же список - в широком доступе. Все схемы и прочая информация предоставляются сторонним организациям (вспомните о многочисленных утечках информации). Хорошенькая борьба за конфиденциальность! Лично меня не радует, когда я вложу 20 миллионов в проект, а затем обнаружу на рыночном развале CD типа "Средства защиты конфиденциальной информации Российских клиник" с полным описанием и схемами информационной безопасности своей клиники.


Именно.

Кстати, еще информация. Роскомнадзор (http://www.rsoc.ru/) - регулятор по персональным данным, входит в состав Минкомсвязи (http://www.minsvyaz.ru/) в качестве структурного подразделения. А теперь попробуйте это. Сразу. http://palm.newsru.com/russia/15may2009/firstvictims.html Хотя, может, и "утка".

Обычно персональная информация отдельного человека не представляет большого интереса (если кого-то и заинтересует ИБ Иванова И.И., получавшего лечение с ... по ... в ..., то заполучить копию ИБ, скорее всего, будет достаточно просто). Косвенно это подтверждает то, что регламентируется именно электронный вариант ИБ. Т.е., возможность получения доступа к большому объему информации. А здесь автоматически возникают другие вопросы. Кому, потенциально, может быть интересна такая информация и для чего?
Вполне возможно, что, как это обычно бывает и у вас, и у нас, "зонтиком" закрыли вопрос об ограничении доступа к персональной информации, не подумав о том, кого еще это затронет, и не просчитав риски и стоимость предполагаемого эффекта.

Обратите внимание - ФСТЭКом не сертифицирован ни один аппаратный межсетевой экран, включая последние модели ведущих мировых производителей. ... Сертифицированы десяток программных самоделок местных умельцев...
Это как раз понятно почему. Сколько фирм и фирмочек покормились на распространении средств защиты.

Подключать к сетям общего пользователя свою локальную сеть, используя только программный файерволл, неразумно. У меня даже дома аппаратный экран стоит.
Здесь позвольте не согласиться . Cisco -- всего лишь специализированный компьютер. А CheckPoint -- програмно-аппаратный комплекс. Компьютер под, скажем, freeBSD с правильно настроенной маршрутизацией и брандмауэром будет работать не хуже той же Cisco 36 или 39 серии. А то и гибче.
А есть ведь еще и VLANы для сегментации сети. А для доступа извне -- VPN, IPSec, SSH. Тем более, что по данным того же Oracle, подавляющее большинство угроз данным обусловлено непреднамеренными или намеренными действиями вполне легальных пользователей сети.

В книге Джона Чирилло "Обнаружение хакерских атак" утверждается, что само наличие и тип средства защиты - это уже должно быть большой тайной для хакера.
Все же, мне кажется, хакеры вряд ли являются основными заинтересованными мед. данными лицами . Информация о том, что в качестве сетевого экрана используется, например, CheckPoint, вряд ли сильно поможет при организации внешней атаки.

Кстати, еще информация. Роскомнадзор (http://www.rsoc.ru/) - регулятор по персональным данным, входит в состав Минкомсвязи (http://www.minsvyaz.ru/) в качестве структурного подразделения. А теперь попробуйте это.
У вас -- электронное правительство, у нас -- электронная Беларусь. Результат один и тот же .

К сожалению? Святая наивность! http://www.iksmedia.ru/blogs/post/449145.html Это еще минимально радикальное мнение.

Я уже цитировал п. 1 ст. 22 Закона 152. Процитирую п. 2 этой же статьи: "Оператор вправе осуществлять без уведомления уполномоченного органа по защите прав субъектов персональных данных обработку персональных данных: ... 2) полученных оператором в связи с заключением договора, стороной которого является субъект персональных данных, если персональные данные не распространяются, а также не предоставляются третьим лицам без согласия субъекта персональных данных и используются оператором исключительно для исполнения указанного договора и заключения договоров с субъектом персональных данных; ...". Т.е., достаточно заключить с пациентом договор (а многие клиники так и делают) на оказание медицинских услуг - и можно использовать для информационной защиты стандартные (возможно, несертифицированные), но эффективные средства, не получать лицензию на защиту информации и т.д. Кстати, в договоре учесть согласие на передачу данных в установленном законом порядке. Наверное, это является основанием того, чтобы все существующие медицинские информационные системы (МИС) могли быть выведены "из-под удара" Закона. Это мое личное мнение.

Однако некоторые авторы так не считают, а напротив, утверждают, что МИСам должна быть установлена максимально возможная конфиденциальность и максимальная группа по защите персональной информации (= максимально возможные затраты, ведущие к полной нереализуемости МИСов в существующих условиях, что, впрочем, самими авторами и признается). См., например, http://www.consultant.ru/online/base/?req=...MED;n=31473;p=1, а также http://www.consultant.ru/online/base/?req=...ase=MED;n=29496.

Боюсь, что так легко не получится. Данная фраза об отсутствии уведомления не снимает всех требований к информационной защите, т.е. лицензионные органы могут просто проверить, насколько МИС исполняет требования 152 закона и связанных с ним подзаконных актов, даже если уведомления и не было. Во-вторых, договор будет только относительно платных услуг, а их в медицине меньшинство и большая часть ОМС и ДМС не будет прикрываться даже этой лазейкой.
Кроме того, конструкция статьи предполагает информацию, относящуюся к договору (в связи с заключением), т.е. законодатель имел в виду то, что содержится в договоре, а не дополнительную информацию, получаемую в ходе работ выполняемых и предоставляемых услуг по договору.

А вот еще проблема, на которую указали коллеги. Это - современное медицинское оборудование: томографы, цифровые рентгеновские аппараты, УЗИ и т.д. Все эти аппараты содержат встроенные компютеры и встроенные базы данных по пациентам. Уверен, что ни один из этих аппаратов должным образом не сертифицирован. И вряд ли возможно такую сертификацию провести (не повезете же вы томограф весом 5 тонн в соседний город на сертификацию).

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

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

В любой БД ФИО хранится только как информационное поле (правда, может использоваться для связывания с другими БД) и используется для поиска. Вся информация, относящаяся к пациенту, связывается по паре первичный-внешний ключ. Таким образом, если первичный ключ продублировать на ИБ, возможна однозначная идентификация пациента. Особенно, если первичный ключ будет формироваться по определенным правилам и с ИБ вводиться посредством считывания штрих-кода.

А внимательно прочитать, что это случайный ключ? Не задумывались, что слово случайный и "формируются по правилам" вещи несовместные?

1. В БД, которые являются основой любой информационной системы, использование случайного числа в качестве первичного ключа вряд ли можно считать оправданным подходом. Во всех современных БД есть эффективные внутренние функции для генерации последовательностей, применяемых в качестве первичного ключа. Использование собственных генераторов ключей в большинстве случаев является нецелесообразным, поскольку может оказать неоправданную назгрузку на систему.
2. Честно говоря, не вижу причин, почему последовательно формируемый ключ не может использоваться в качестве идентификатора пациента, с одной стороны скрывающий его ФИО, с другой -- обеспечивающий однозначное соответствие.
3. Под "формируемым по правилам" ключом лично я имел ввиду диапазоны чисел, отводимые, например, отдельным диспансерам, входящим в одну службу.

Совершенно верно, но не обычные пользователи.

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

Если администраторы упомянутых баз данных имели возможность безнаказанной кражи этих самых данных данных до принятия обсуждаемого пакета законов, точно также они будут иметь такую возможность и после принятия и вступления в действия данного пакета законов, независимо от того, имеет Windows рабочей станции сертификат ФСТЭК или нет, сертифицирован файервол или нет.

Речь идет о том, можно ли идентифицировать пациента по записи в базе данных, из которой (из записи) удалены поля ИМЯ, ФАМИЛИЯ, АДРЕС, НОМЕР ПОЛИСА и т.д. Причем идентифицировать БЕЗ ПРИВЛЕЧЕНИЯ дополнительной информации. Естественно, если в бумажной ИБ имеется паспортная часть, содержащая номер записи в электронной ИБ (этим номером может быть хоть номер истории болезни, хоть некое случайное число, записанное хоть числами, хоть штрих-кодом - который на самом деле является просто особым шрифтом, хоть и тем, и другим одновременно - неважно), то понятно, что эта запись относится к данному пациенту (иначе вообще зачем нужна эта МИС).

Запись в ЭИБ без паспортной части как раз и будет обезличенной. И этот подход считаю единственным, позволяющим формально выполнить закон (ценой некоторого снижения функциональности) без привлечения финансовых средств, которых, собственно, и так нет.

Вообще-то разговор идет не о правилах формирования БД, а о том, как можно работать в условиях существующей нормативной базы. Поскольку в законе идет речь о деперсонализированных данных, любые методы, которые могут быть использованы для сопоставления открытой и закрытой информации достаточно легко не могут являться приемлимыми. Альтернативой "неоправданной назгрузки на систему" является сертификация эхокардиографа во ФСТЭК.
И просьба, не надо предполагать, что люди, пишущие в форум не имеют представления о базах данных, и повторять поэтому очевидные вещи. Если кто чего не понимает, спросит - иначе это - флуд.

Есть еще идея, может, дикая.

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

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

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

Есть технологии, позволяющие исключить подобное со стороны БДА, -- у Oracle -- DB Vault, у MS -- управление на основе политик (SQLServer 2008). Правда не знаю, сертифицировано ли это. Но стоимость подобных решений высока.

Не знаю, как с точки зрения закона, но мне эта идея нравится.
...
В нашей ЭИБ как раз реализован принцип двух баз, объединенных оболочкой. Первая база - база ТФОМСа, вторая - собственно больничная.
Не знаю, как ТФОМС будет свою базу регистрировать.. У нас привязка на номер страхового полиса. По сути - это и есть искомый идентификационный номер. Так, что осоо придумыввать не надо будет.
Видимо, прдется на бумажнею ИБ выносить крупным шрифтом номер полиса и на табличку рядом с пациентом, где сейчас его ФИО и диагноз добавить номер полиса. Так врачи быстрее запоминать будут. Плюс, при прочтении заметок я могу почти на 98% угадать, о каком моём пациенте идет речь.
Проблема деперсонализации данных, действительно, очень серезная и пока даже толком не осмыслена.
...
Здесь на форуме уже обсуждались ЭИБы. Не увидел, про Ирис упоминали? Демо-версия концептуально мне понравилась.

Совсем свежая информация о положении дел с персональными данными: http://www.kommersant.ru/doc.aspx?DocsID=1176806 Защитники персональных данных хотят 100 млрд. рублей в ближайшие 2 года.

Шокирующие данные приводятся в следующей информации http://www.aksimed.ru/company/news_1/iz.php?ELEMENT_ID=290 Мы склонны по своему менталитету не учиться на опыте других, а это следовало бы делать.

Поэтому рискну подвести промежуточный вывод в обсуждении темы: внедрение компьютерных информационных систем в Российское практическое здравоохранение на уровне отдельных учреждений, несмотря на всю привлекательность современных информационных технологий, в силу комплекса причин законодательного, финансового и технического характера нерационально и преждевременно. Хотя научные исследования в данном направлении желательны.

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

В русле рассматриваемой темы это приводит к тому, что решая проблему персональных данных, в кучу дополнительно валят проблему конфиденциальных данных и проблему коммерческой информации. Уважаемые, не делайте так. Обращение конфиденциальных данных регулируется отдельным законодательством (в поликлинике их практически нет, а там, где есть, все уже давно организовано). А проблема коммерчески важной информации (которой в поликлинике нет вообще) вообще решается внутренней политикой учреждения, при соблюдении действующего законодательства, естественно. Какой там уровень конфиденциальности 1Б и т.п. в МИСе, как пишут некоторые горе-авторы? Нет в законе "О персональных данных" такого понятия! В подзаконных актах есть только 4 класса для персональных данных: К1...4. И всё! Берем класс для обезличенных данных - и по закону можно даже уведомления о намерении стать оператором не делать!

Попробуйте программы для клиник с сайта www.apdent.ru
Для небольших локальных сетей (20-30 раб.ст.) вполне годятся. И цены там вполне приемлемые.

На указанном сайте отсутствует информация, сертифицировано ли предлагаемое программное обеспечение ФСТЭК для работы с персональными данными. Сегодня это очень важная конкурентная информация. Если не указано, возможно, что не сертифицированы.

Кстати, об Access. Он практически негоден для коллективной работы, хотя формально и позволяет это делать. Для коллективной работы следует установить сервер баз данных (пусть даже на одной из рабочих станций под Windows XP, а не на специализированном сервере). Например MS SQL Sever, Oracle, MySQL (список не исчерпывающий). Для первых двух коммерческих продуктов имеются бесплатные версии (с ограничениями на размер базы данных в 4 Гб), а третий продукт - бесплатный. Создание базы данных в данных продуктах лишь немногим сложнее Access благодаря имеющимся бесплатным средствам администрирования и поддержки. Недавно консультировал аналогичный учебный проект. Кого интересует, могу дать ссылки.

К примеру, можно загрузить бесплатную версию SQL Server 2008 (все компоненты, в т.ч. SQL Server Management Studio и вся документация - на русском языке), взять известную книжку Д.П. Мак-Мануса с соавт. и прямо по книге проделать ряд шагов по принципу "укажи мышкой и кликни". Хотя в книге даны примеры для английской версии 2000 (а приведенный пример типичной базы данных управления заказами может быть легко адаптирован - карточка пациента, включая паспортную часть и посещения - та же система управления заказами), но все совершенно очевидно и в имеющейся русской версии 2008. Для других серверов (в дополнение к упомянутым - также SQLite) все немногим сложнее.

В предыдущем посте я давал ссылку на прогноз затрат на реализацию законодательства "О персональных данных". Много это или мало? Все познается в сравнении. Вот тут статья о затратах на здравоохранение в России http://ethnocid.netda.ru/analitika/akchurin.htm. См. раздел 2 "Финансирование здравоохранения".

Пройдет ли? То, что данные о ФИО вынесены в отдельную БД по существу означает лишь физическое разделение данных и способ их хранения. Насколько я понимаю, для ввода и просмотра информации о конкретном пациенте на уровне приложения будет происходить объединение необходимых сведений. Т.о., система будет автоматически попадать под требования сертификации по классу К1.
Опять таки, насколько понял сами постановления, любая система, позволяющая автоматически сопоставить ФИО и медицинские данные, попадает по сертификацию.

P.S.
В постановлениях есть пункт об обязательной фиксации: кто, когда, к чему и для чего получал доступ. Есть ли сейчас в ваших медицинских системах подобное? В используемых в Белоруссии, насколько я знаю, подобного нет.

Конечно, не пройдет. Потому я и поправился в начале.

Если исходить из реальностей и из того предположения, что ФСТЭК и ФСБ будут исполнять законы как положено (а они всегда так и поступают), фактически идея использования госпитальных информационных систем (тем более полный переход на электронные истории болезни) становится мифом (как и обсужденный выше национальный стандарт - бесполезным). Большую неосторожность совершили те клиники и/или территории, которые имели нетерпение сделать это. Например, в свое время мы с очень большим интересом изучали опыт Воронежа, Татарстана, где были большие достижения в рассматриваемой области. Оказалось, зря. Самое интересное, что никаких распоряжений Минздрава на счет создания электронных историй болезни никогда, насколько нам известно, не было. Всегда и везде это были чьи-то личные инициативы, граничащие, как теперь оказывается, с нецелевым использованием бюджетных средств, что, как известно, является уголовным преступлением.

Компьютерам, однако, использование в клинике не заказано. Выше я давал ссылку на сайт компании AKSIMED. Компания бесплатно предлагает набор шаблонов для оформления клинической документации. Подобные же самодельные шаблоны (без использования каких-либо баз данных - т.е. после ввода и печати, скажем, выписки, ни в какой базе информация о пациенте не сохраняется и тут же уничтожается) применяют много врачей, лаборантов и сестер. Уже одно это, по нашему опыту, сильно экономит время клиницистов и работников лабораторий.

Закон "О персональных данных" суров, но вряд ли кто возразит, что он справедлив и необходим для пресечения той информационной вакханалии, которой мы все оказались свидетелями. Средств на его реализацию в медицине, однако, нет и не будет в ближайшие лет 50, а значит - никогда. Поэтому, например, буквально недавно при составлении задания на проектирование корпоративной информационной системы в одной из клиник, как мне стало известно в беседе с коллегами, было принято решение оставить в системе только финансовую и документальную часть, полностью отказавшись от использования каких-либо персональных данных пациентов. Поэтому карточка пациента будет применяться исключительно в бумажном варианте, несмотря на прекрасную оснащенность клиники компьютерами и отличным сетевым оборудованием. В общем-то, ничего страшного не произошло. Компьютерам и без того работа найдется.

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

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

Вот что дает соответствующий запрос на сайте Oracle http://www.oracle.com/technology/deploy/se...valuations.html.
Т.е., ознакомившись с сертификатами (почти 10 лет, как просроченными), можно сделать вывод, что сертифицированы (предшественником ФСТЭК) не серверы Oracle как таковые, а 2 (!) конкретных экземпляра Oracle, под конкретную конфигурацию оборудования (UNIX сервер HP) и с конкретным дополнительным ПО. Из данной информации делаем вывод, что ни одно решение по МИС, предлагаемое ныне на данном рынке, требованиям не соответствует. Хотя конкретное решение может быть сертифицировано самим разработчиком прикладного ПО, информации о такой сертификации не представлено.

В том то и дело, что при использовании DB Vault (и его аналогов) администратор, имея доступ к физическим файлам, доступа к данным может и не иметь (в отличие от ситуации, когда DB Vault не установлен). Т.е., физическое копирование файлов не имеет смысла.

Действительно, по данным Интернета (кстати, ни слова на официальном сайте Oracle - следовательно, сертифицирована не серия - см. ниже) Oracle 11g R1 (11.1.0.7) + опция Database Vault сертифицирована (номер сертификата 1849 от 25.05.2009) по требованиям ФСТЭК России для защиты персональных данных (152-ФЗ) до класса 2, включительно. Но в данной информации опять же - непонимание сути сертификации в России. Если одна копия, представленная на сертификацию, сертифицирована, то это не значит, что сертифицирована вся серия продуктов (хотя такое и возможно). При покупке продукта нужно учесть, что 1) у конкретного образца должен быть сертификат и 2) срок действия сертификата ограничен. Т.е., после окончания срока действия сертификата придется 1) приобрести новый продукт или 2) продлить сертификат на конкретный продукт (тут могут быть сложности - например, в свое время была сертифицирована Windows XP SP1 - сегодня о безопасности такой системы можно рассуждать лишь с улыбкой; грубо говоря, продукт портится со временем, т.к. изобретаются новые угрозы, что справедливо и удостоверяет сертификат).

Еще немного о сертификации. Скажем, вы ставите на компьютер сертифицированную версию Windows и намерены безопасно работать в Интернете... если вы, конечно, информационный "самоубийца" - минут на 5 вас хватит. Вы не можете установить сертифицированную версию Windows и безопасно работать, не установив дополнительно файервол и антивирус. Т.о., хоть какая-то минимальная безопасность обеспечивается при наличии других программных продуктов, помимо сертифицированной версии Windows. Вот мы и доказали, что сертификация одного продукта - профанация идеи информационной безопасности. Сертифицироваться должен конкретный программно-аппаратный комплекс + комплекс организационных мероприятий, и никак иначе. Причем сертификация касается всей номенклатуры применяемых программ - например, хочешь ICQ на рабочем месте - сертифицируй ICQ во ФСТЭК - причем и сервер в Калифорнии, и все 30 млн. клиентов. Хочешь mail.ru агента - аналогично. Хочешь Total Commander - и его тоже. Захотел Microsoft Office - есть сертифицированная версия. А захотел статистику посчитать в AtteStat для Excel - сертифицируй AtteStat (обратите внимание на последний раздел Лицензионного соглашения AtteStat - он там с 2002 года).

Вот тут попалась информация по Database Vault http://www.aladdin.ru/press-center/publica...cation19697.php. Цитата из нее: "... проблема, в принципе, могла бы быть решена с помощью совместного использования опций TDE и Oracle Database Vault, но в этом случае полномочия администратора СУБД плавно перетекают к администратору Database Vault, т.е. проблема защиты от привилегированных пользователей сохраняется". Так можно бесконечно контролировать друг друга. Безопасная система должна быть построена так, чтобы ее невозможно (или не нужно) было украсть.

1. Я как раз об этом и писал ранее. Более того, в сертификате (вернее, в сопроводиловке) должны быть оговорены и условия замены оборудования в случае выхода из строя каких-то компонент. И Вы совершенно правы, что, если брать ad maximum, то можно, к конце концов, дойти до маразма.

2. Лично я указанную информацию с aladdin'а воспринимаю с хорошей долей скептицизма. Причина проста -- предлагаемые ими продуктыявляются конкурентами, в частности, DB Vault.

Одна из причин разработки средств типа DB Vault -- избыточные полномочия администратора БД. Желаемый принцип -- администратор БД должен управлять БД, а не ее содержимым. Происходит разделение полномочий: админ может скопировать файлы, но не может получить доступ к информации. Офицер по безопасности (в терминах Оракл) имеет доступ к управлению видимостью информации, но не имеет доступа к файлам.

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

Попалась свежая публикация, которая для меня решила вопрос. http://newsru.com/finance/03jul2009/montenegro.html Суть публикации - в России запрещен игорный бизнес. Если издается закон, ставящий неприемлемые, невыполнимые условия бизнесу - фактически это закон о запрещении данного вида бизнеса. Что такое закон о персональных данных для медицины? Фактически это закон о запрете медицинских информационных систем.

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

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

УКАЗ Президента РФ от 06.03.1997 N 188 (ред. от 23.09.2005)
"ОБ УТВЕРЖДЕНИИ ПЕРЕЧНЯ СВЕДЕНИЙ КОНФИДЕНЦИАЛЬНОГО ХАРАКТЕРА"
п.4
"Сведения, связанные с профессиональной деятельностью, доступ к которым ограничен в соответствии с Конституцией Российской Федерации и федеральными законами (врачебная, нотариальная, адвокатская тайна, тайна переписки, телефонных переговоров, почтовых отправлений, телеграфных или иных сообщений и так далее)."

ст. 61 Основ законодательства Российской Федерации об охране здоровья граждан:
"Информация о факте обращения за медицинской помощью, состоянии здоровья гражданина, диагнозе его заболевания и иные сведения, полученные при его обследовании и лечении, составляют врачебную тайну. Гражданину должна быть подтверждена гарантия конфиденциальности передаваемых им сведений."

Достаточно?

Да, конечно, спасибо.

Мы считаем, что для реализации данных законов достаточно стандартных аппаратно-программных средств и стандартных же процедур, утвержденных органами управления здравоохранением (мое личное мнение - достаточно уровня учреждения).

ПРИКАЗ ФСТЭК РФ N 55, ФСБ РФ N 86, Мининформсвязи РФ N 20 от 13.02.2008 ?ОБ УТВЕРЖДЕНИИ ПОРЯДКА ПРОВЕДЕНИЯ КЛАССИФИКАЦИИ ИНФОРМАЦИОННЫХ СИСТЕМ ПЕРСОНАЛЬНЫХ ДАННЫХ? (Зарегистрировано в Минюсте РФ 03.04.2008 N 11462)
"определяются следующие категории обрабатываемых в информационной системе персональных данных:
категория 1 - персональные данные, касающиеся расовой, национальной принадлежности, политических взглядов, религиозных и философских убеждений, состояния здоровья, интимной жизни;"

ст. 22 Закона 152-ФЗ (О персональных данных)
"Оператор вправе осуществлять без уведомления уполномоченного органа по защите прав субъектов персональных данных обработку персональных данных..." и там истории болезни нет, т.е. данные истории болезни не могут обрабатываться без уведомления уполномоченного органа, а далее - см выше.

По приказу (приказ трех) данные отнесены к специальным информационным системам
"К специальным информационным системам должны быть отнесены информационные системы, в которых обрабатываются персональные данные, касающиеся состояния здоровья субъектов персональных данных;"

Соответственно, явно идет в дело Постановление Правительства Российской Федерации от 31 августа 2006 г. ? 532 ?О лицензировании деятельности по разработке и (или) производству средств защиты конфиденциальной информации?

А там:
"3. Лицензионными требованиями и условиями при осуществлении деятельности по разработке и (или) производству средств защиты конфиденциальной информации, лицензирование которой отнесено к компетенции Федеральной службы по техническому и экспортному контролю, являются:
а) наличие в штате соискателя лицензии (лицензиата) специалистов, имеющих высшее профессиональное образование в области технической защиты информации либо высшее или среднее профессиональное (техническое) образование и прошедших переподготовку или повышение квалификации по вопросам технической защиты информации;
б) наличие у соискателя лицензии (лицензиата) помещений для осуществления лицензируемой деятельности, принадлежащих ему на праве собственности или на ином законном основании;
в) выполнение требований конструкторской, программной и технологической документации, единой системы измерений, системы разработки и запуска в производство средств защиты конфиденциальной информации, а также иных нормативных правовых актов Российской Федерации в области технической защиты информации;
г) соответствие помещений, производственного, испытательного и контрольно-измерительного оборудования, предназначенных для осуществления лицензируемой деятельности, техническим нормам и требованиям по технической защите информации, установленным нормативными правовыми актами Российской Федерации;
д) наличие нормативных правовых актов, нормативно-методических и методических документов по вопросам разработки средств защиты информации в соответствии с перечнем, установленным Федеральной службой по техническому и экспортному контролю. "


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

Ситуация 1 (касательно Основ законодательства Российской Федерации об охране здоровья граждан). Пациент экстренно госпитализируется. В соответствии с законом передача больницей информации о его местонахождении в данном лечебном учреждении родственникам пациента без согласия пациента (пусть даже такое согласие получить нельзя ввиду тяжелого состояния пациента) является нарушением закона? Да и гарантию пациенту в данном случае подтвердить затруднительно. Тогда уже сейчас нужно судить каждого главного врача, ибо в каждой больнице список пациентов (= факт обращения) по палатам и отделениям (= почти диагноз) вывешен в приемном покое и с пациентов согласие на включение в данный список вряд ли получено. А недавнее нововведение в популярной программе "Жди меня" - фото и диагноз пациента, потерявшего память, были [успешно] использованы публично для поиска его родных - с точки зрения цитируемого закона - вообще уголовщина. Представляется, что закон оторван от реальности.

Ситуация 2 (касательно закона о персональных данных). Как вы думаете, что бы выбрал пациент: а) его данные будут занесены в несертифицированную информационную систему или б) его данные будут занесены в сертифицированную информационную систему, но ему придется заплатить за прием 1000 руб. (в пользу сертифицирующего органа), или в) никакой информационной системы нет, но в очереди придется посидеть часа 2 и качество обслуживания ухудшится на 20%? Причем информационная система и в том, и в другом случае - одна и та же (выше я уже давал ссылку на официальную позицию компании Microsoft - у других поставщиков ситуация, уверен, аналогична). Наверное, все граждане выбрали бы вариант а) - закон, правда, этого им сделать не позволит. Законодатель, естественно, хотел вариант б) - 100 млрд. рублей на дороге не валяются (выше я также давал ссылку). А реализован, к сожалению, будет вариант в), т.к. денег нет. Как всегда - один хочет одного, другой - другого, а получится то, чего не хочет ни тот, ни другой. Кстати, деньги были бы, если бы последним пунктом закона было: "Минфину выделить целевым порядком необходимое бюджетное финансирование в размере 100 мрд. рублей". Представляется, что закон также оторван от реальности.

Вообще, нехорошо, когда законы либо в принципе не работают, либо одномоментно делают преступниками десятки тысяч человек. Что-то не то с законами. Понятно, закон работает в данном случае на предотвращение преступления. Но мероприятия по предотвращению преступления не должны наносить ущерб больший, чем само предполагаемое преступление. Не правильно, предполагая преступление или даже основываясь на единичных реализованных преступных случаях, терроризировать или лишать определенных прав всех законопослушных граждан. Если декларируемая цель мероприятия не достигается, значит реальная цель была другая. Разве что целью не является борьба с преступностью путем отнятия у преступника (превентивного уничтожения) объекта его посягательства. Нет объекта - не будет и преступления?

В комментариях и обсуждениях можно найти информацию, что законодательство о персональных данных было принято с целью гармонизации отечественного законодательства с международным (европейским, в частности). На самом деле, это неправда. Докажем на примере главного отличия. Отечественная система сертификации ПО принципиально отличается от европейской (международной). Отличие в том, что в России сертифицируется каждый экземпляр продукта. Компания Microsoft, например, приняла такой порядок с нескрываемым восторгом. Организация, владеющая 300 компьютерами, могла бы купить корпоративную лицензию Windows (+ различные скидки, в зависимости от статуса организации) по причине того, что сама Windows уже сертифицирована на соответствие европейским критериям безопасности. Это в Европе. У нас организация вынуждена покупать 300 сертифицированных коробок устаревшей (срок получения сертификата - до 1 года, кроме того, парадокс - пакет обновлений за 1 год с точки зрения отечественного закона ухудшает информационную безопасность) профессиональной версии, что в разы повышает стоимость уже не нового ПО. Далее, для оперативного и дешевого обновления Windows организация ставит сервер WSUS (кстати, бесплатный - рекомендую), ибо о безопасности Windows как операционной системы можно рассуждать лишь теоретически и с улыбкой. В России сервер WSUS не сертифицирован - значит, вне закона ключевой элемент безопасности корпоративной сети (второй ключевой элемент - сервер администрирования антивируса - не слышал, чтобы он был тоже сертифицирован), поэтому с некоего специального сервера будет обновляться каждая копия. Не нужно доказывать, что такая схема в разы же уменьшает реальную безопасность (в сеть выходит каждый компьютер либо программист вручную ставит обновления на все рабочие станции, причем со значительной задержкой выпуска) и во столько же увеличивает стоимость владения (на 300 компьютеров при централизованном управлении достаточно одного сетевого администратора - при ручном надо будет человек 15).

По поводу предыдущего абзаца мне могут возразить, что система сертификации не относится к закону о персональных данных. Сразу отвечу. Если закон отдает сертификацию "на откуп" подзаконным актам, то эти акты и система сертификации относятся к обсуждаемому закону. Точнее сказать, должен обсуждаться в этом случае не сам закон в отдельности, а пакет законов о персональных данных. К исполнению также обязателен именно пакет законов и подзаконных актов. Это - одно целое.

Наверное, мы к этой проблеме вернемся (собственно, это и будет основной и единственной проблемой). Но уже сейчас весьма напрягает отсутствие системы критериев, по которым производится проверка организации. В принципе, имея всё сертифицированное оборудование и ПО, железную дверь и решетки на окнах регистратуры, оформленную документацию о допусках, электронные ключи, все лицензии, к вам может, скажем, возникнуть вопрос - а сертифицирован ли у вас кабель "витая пара" (кто не знает - применяется для сетевых соединений)? Нет? А вот нате Вам: штраф, предупреждение о грядущем закрытии учреждения, изъятие всех компьютеров на 3 месяца для проверки и т.д., т.п. Не верится? А зря. С месяц назад приходила группа (не скажу - мошенников) специалистов с предложением услуг по разработке информационной системы. Первым (даже не взглянув) было - а мы Вам весь кабель (10 км) заново проложим, т.к. у Вас кабель, наверное, не той модели. Как? У вас категории 5e, а также оптика и все оборудование сертифицировано? Ну все-равно переложим, т.к. наша информационная система будет работать только с нашим кабелем. После чего направились к руководству, сообщили им о низкой квалификации всех программистов и персонала и пообещали решить проблему за несколько десятков (!) миллионов рублей. Список не исчерпывающий: есть еще коннекторы, кабель-канал, коридоры, по которым проходит кабель-канал, столбы подвески, грозоразрядники, улица, которую пересекает подвешенный кабель (а по улице шпионы и хакеры на автомобилях ездят), коврик для компьютерной мыши и стол, по которому она ползает.

Кто же мешает задать тот же вопрос проверяющими? Закон позволяет.

Ловим шпионов в поликлинике. А тем временем в интернете циркулирует снятое мобильником фото певицы Людмилы Зыкиной, тайно сделанное в морге. Вот так - закон в [без]действии. Или теперь уже не 100 миллиардов нужно, а 200?

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

1) В случае экстренной госпитализации пациент либо (а) может сам выразить свою волю, тогда см. Основы, либо (б) не может, тогда решения принимают родственники или (если времени их оповестить нет) - консилиум. Так что в Основах все логично и правильно прописано. Не стоит фантазировать насчет его оторванности от реальности. Не будем углубляться в понятие дееспособности и того, кто принимает решения в отношении недееспособного пациента, но там опять-таки не все так просто и надо разбираться кто и почему показывал.

2) Пациент выберет занесение данных (бесплатное) в бумажную историю болезни. Ничего страшного в том, чтобы не плодить недоделанные электронные истории болезни нет. И ничего эти электронные системы в отношении ускорения работы (по крайней мере в первые пять лет после внедрения) не делают. Так что опять-таки, закон абсолютно нормальный - можете сделать нормально защищенную систему, считаете, что она окупится - вкладывайтесь. Не можете, не надо делать уродцев.

Абсолютно согласен.

У нас появилось предложение, которое хотелось бы донести до управления здравоохранением (возможно ли это?). Приемлемое недорогое решение, на наш взгляд, в общих чертах выглядеть может так. Идея возникла из опыта некоторых учреждений, в которых карточка пациента хранится на руках у самого пациента.

Основные положения:
1. В учреждениях здравоохранения хранятся обезличенные базы данных. Персональной части вообще не хранится. Доступа на запись к базе сотрудники учреждения не имеют, пока не будет введен особый ключ. При этом доступ на чтение, для целей статистики, научного и экономического анализа, у специалистов учреждения имеется с использованием стандартных средств аутенфикации.
2. Ключ (можно назвать его паспортом здоровья) пациент приносит с собой. Полный доступ к базе осуществляется только при наличии ключа - как в банковском терминале. Персональные данные как раз хранятся в данном ключе. За их сохранность отвечает сам пациент.
3. Ключ пациенту выдает специальный территориальный уполномоченный центр. Право записи и хранение копии персональных данных ключа имеет только данный центр. При утрате данного ключа порядок действий аналогичен, скажем, действиям при утрате любого другого документа.

Таким образом, данное предложение обеспечивает:
1. Максимальный уровень защиты (выше него - только если пациент носит всю историю болезни с собой на карточке).
2. Полное исполнение всех законов и законодательных актов.
3. Минимальную цену (если записи обезличены, сертификация аппаратно-программных средств, в особенности на рабочих местах, в отдельных учреждениях вообще не нужна).
4. Полную стандартизацию всех учреждений здравоохранения страны в части медицинских записей. При этом структура части базы может быть одинаковой для всех учреждений, специальная часть (зависящая от профиля учреждения) может быть уникальной и даже редактироваться самим учреждением.
5. Полный доступ к информации (при необходимости) по решению суда, со стороны компетентных органов и в других случаях, определенных законодательством, но не со стороны злоумышленников - физически исключаются как опасности несанкционированного распространения или искажения информации от вторжения хакеров, так и злонамеренные действия внутри самого лечебного учреждения.

Недостаток (хотя он может рассматриваться и как преимущество) - необходимо создание сертифицированных уполномоченных центров (возможно, по одному на субъект - не так уж и много) в рамках территориальных органов здравоохранения под контролем всех уполномоченных органов. Возможно наделение данными функциями существующих органов - например, государственного Пенсионного фонда или ФОМС.

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

Вот именно о такой ситуации и шла речь в посте. Недавно анализировал заявку одного из операторов, поданную, в соответствии с законом, до 1 января 2008 года. Внесен в реестр операторов он был в апреле 2008 года. При этом, что характерно, рекомендации по заполнению заявки были официально изданы лишь в июле 2008 года. К чему привела поспешность, могу пояснить: организация написала в заявке все, что пришло в голову нерадивому исполнителю, включая расширительные формулировки, о которых сказано выше, вплоть до трансграничной передачи данных (о которых на самом деле речи нет и никогда не будет). Тем удивительнее для руководителя организации были жесткие и конкретные вопросы проверяющих, причем заданные в точности по заявке. Организация взяла на себя обязательства, для реализации которых не хватит и 10 миллионов рублей! А можно было обойтись реально десятком тысяч. Сейчас будет идти "тяжба" о коррекции заявки. Уволить бы еще этого исполнителя!

http://www.bob2000.pisem.net/ - АРМ врача (электронная история болезни) Acctss
http://reanclub.info/load/1 - Реанимационный клуб - различные авторские программы
http://www.medsoft.ucoz.ua/ - электронная история болезни, база пациентов Access, Укр.

Интересное сообщение. Спешу поделиться http://medportal.ru/mednovosti/news/2009/08/21/uselmed/.